Jump to content

在 Windows 操作系统下编译 LibreOffice 的技巧及提示

From The Document Foundation Wiki
This page is a translated version of the page Development/BuildingOnWindows and the translation is 14% complete.
Outdated translations are marked like this.

Introduction

Windows Subsystem for Linux (WSL) is a mechanism to run Linux applications unchanged in Windows. You can use WSL to build LibreOffice for Linux and run it on Windows, or you may use WSL as a helper to configure LibreOffice build, and then use GNU make to build it for Windows using Visual Studio. Here we discuss building for Windows. To build for Linux, please refer to Development/BuildingOnWSL, but note that this method is not actively supported.

These instructions assume you have not installed any WSL container. The automated steps install an Ubuntu WSL container and the required packages only, if existing containers are not found. If you have an existing container, you may need to enter it and install packages manually. See the relevant winget file in the source code and its definition of the needed packages near the end.

Dev Drive

Windows 11 offers the possibility to create storage volumes called Dev Drives, which improve performance when doing development. Using a Dev Drive has the additional benefit of avoiding errors caused by anti-virus tools. If you don't use a Dev Drive, make sure your anti-virus software will not cause any problems. The instructions below assume LibreOffice source code goes into your user directory, so if you decide to use a Dev Drive, after running the winget commands, copy everything over to the Dev Drive and adapt accordingly.

Cloning the source code and installing build dependencies

Launch Windows Command Prompt as a normal user and run the following:

Command to install Git (run as normal user in Command Prompt)  

winget install -e --id Git.Git

Start Git Bash and run the following:

Command clone LibreOffice source code (run in Git Bash)  

git clone --config protocol.version=2 --config core.autocrlf=false https://git.libreoffice.org/core lo/libo-core

The cloning options use a more efficient protocol and prevent messing up line endings in files. If you want to set these options globally as the default, give the command git config --global protocol.version 2 ; git config --global core.autocrlf false

Launch another Command Prompt window as administrator (right-click, Run as administrator). Run the following:

Winget commands to install Visual Studio and other dependencies (run as administrator in Command Prompt)  

cd %USERPROFILE%
winget configure -f lo/libo-core/.config/configuration.winget
winget configure -f lo/libo-core/.config/admin_java_and_deps.winget

Switch back to the Command Prompt window of your normal user and run the following:

Winget command to install more needed dependencies and a WSL Ubuntu distribution (run as normal user in Command Prompt)  

winget configure -f lo/libo-core/.config/user_steps.winget

This step also creates an autogen.input file in the LibreOffice source code directory with build options. Open the file in a code editor and uncomment the line that says #--enable-dbgutil, if you want to do LibreOffice development with debugging capabilities.

Building LibreOffice

Switch to Git Bash (be sure to not be inside the Linux container!) and run the following:

Commands for installing commit hooks, doing configuration and building of LibreOffice (run inside Git Bash)  

# <span lang="en" dir="ltr" class="mw-content-ltr">edit the autogen.input to your liking and copy to your build directory</span>
cp ~/lo/autogen.input ~/lo/libo-core/autogen.input
cd lo/libo-core
./g -z
wsl ./autogen.sh
make

To also run the tests:

Command to start the build and tests (run inside Git Bash)  

make check

If you hit issues, first consult the known problems section.

Running your build

When the build is finished, you can start LibreOffice with:

instdir/program/soffice

If you want to run specific applications like Writer or Calc, you can invoke:

instdir/program/soffice --writer
instdir/program/soffice --calc

Troubleshooting/Special Scenarios

winget command fails in fresh windows installation  

Windows does some async initializing when logging in the first time/winget might not be fully available from the start. Wait a few minutes or try again.To force it: "If you have recently logged in as a user for the first time and find that WinGet is not yet available, you can open PowerShell and enter the following command to request this WinGet registration:

Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe

winget update --all might also work to force that, but will likely require you to reboot.

Enabling nested virtualization in hyper-v  

While the wsl-as-helper method also works with wsl1, the setup assumes wsl2 is available/can be used by default. There is no UI option in hyper-v manager to enable nested virtualization, you have to do it via a powershell command (assuming your BIOS settings/hardware allows for this in the first place):

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

(don't forget to replace the placeholder with the actual name of the VM, VM needs to be powered off for the command to succeed)

Using wsl1  

In case you cannot (or don't want to) use wsl2, it is also possible to use wsl1 instead, to do so install the windows compontent for wsl1, set the default distribution version to 1, then install the distribution. As Administrator:

wsl.exe --install --enable-wsl1 --no-distribution
wsl.exe --set-default-version 1

As regular user:

wsl.exe --install --distribution Ubuntu-24.04

Disable Defender on a Dev Drive  

You can disable the virus-scanning on Dev Drives completely (by default it would use an async-mode). For this the Dev Drive needs to be trusted (automatically trusted when you created it in the running system, but not when mounting a disk with a Dev Drive created elsewhere). Query the state with

fsutil devdrv query <drive-letter>:

You can explicitly trust it with

fsutil devdrv trust <drive-letter>:

To disable the filesystem filter for the BitDefender/disable the antivirus scanning use:

fsutil devdrv enable /disallowAv

Note that this then applies to all Dev Drives, you cannot selectively disable it for a single one, so use responsibly.

The build crashes  

If you see a message like "Segmentation fault (core dumped)" when building, you have probably run some of the commands in the wrong place, such as inside the WSL container. Examine the config.log file found in the root of the source code. If both the host and build are said to be x86_64-pc-linux-gnu, there is a problem. The host should be x86_64-pc-cygwin. Run make clean and go through the configuration and build steps more carefully.

=== Windows Arm64 交叉编译示例(含Java) ===  

If you're cross compiling to 64-bit ARM, you need to provide a different JDK for the build-tools and the target host. While the build-tools will detect the correct JDK eventually, you must use --with-jdk-home=<Arm64 JDK directory> to provide the host JDK. You can override the build JDK by using --with-build-platform-configure-options=--with-jdk-home=<x64 JDK directory>. Example options for autogen.input:

  • --host=aarch64-pc-cygwin or --with-distro=LibreOfficeWinArm64
  • --with-build-platform-configure-options=--with-jdk-home=C:/PROGRA~1/Java/JDK-17~1.1
  • --with-jdk-home=c:/lode/jdk-17-ea+25-windows-aarch64

The first is the installed Oracle x86_64 Java, the 2nd is the unpacked pre-release of the Windows Arm64 OpenJDK Java.

===== 可选的:创建编译文件夹 =====  

可以 将 LibreOffice 编译到一个单独的文件夹中(而不是您检出的源代码文件夹中)。这样能使得您的源代码目录树保持干净,并使得编译多个版本变得容易。

=== 切换到非默认编译器 ===  

Specify which Visual Studio version to use in case several are installed.

Depending on the branch, different versions may be supported, for example 2015, 2017 for libreoffice-6-1, and typically the oldest supported one will be picked by default.

--with-visual-studio=2019

对于较老的 LibreOffice 版本,需要的 Visual Studio 版本为:

  • LibreOffice 4.4 需要 Visual Studio 2012
  • LibreOffice 5.0 需要 Visual Studio 2013
  • LibreOffice 5.4 需要 Visual Studio 2015
  • LibreOffice 6.2 需要 Visual Studio 2017
  • LibreOffice 6.3 可使用 Visual Studio 2017 或者 2019 编译
  • LibreOffice 7.0 需要 Visual Studio 2019
  • LibreOffice 7.3 可使用 Visual Studio 2019 或者 2022 编译。
  • LibreOffice 4.4 requires Visual Studio 2012
  • LibreOffice 5.0 requires Visual Studio 2013
  • LibreOffice 5.4 requires Visual Studio 2015
  • LibreOffice 6.2 requires Visual Studio 2017
  • LibreOffice 6.3 can be built with either Visual Studio 2017 or 2019
  • LibreOffice 7.0 requires Visual Studio 2019
  • LibreOffice 7.3 can be built with either Visual Studio 2019 or 2022
  • LibreOffice 26.2 can be built with either Visual Studio 2022 or 2026

在 Windows 上运行 Glade

To edit dialogs (.ui files), you need Glade. A Windows build of Glade 3.40.0 is available.

与微软 Visual Studio 项目集成

The LibreOffice build system can generate project files for some IDEs including -- thanks to Honza Havlíček's excellent work -- Microsoft Visual Studio:

Please accept this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

生成 Visual Studio 的项目文件

After a complete build of LibreOffice was successful, execute the following command to generate a Visual Studio project:

make vs-ide-integration

If the generation is successful, the resulting solution file LibreOffice.sln will be placed in the root directory of the build and can be opened with Microsoft Visual Studio.

See Development / IDE / Microsoft Visual Studio for details, including commands used with older branches and known problems.

为什么要使用 MSVC?

这是一个经常被问到的问题,通常来自于自由软件热衷者:我们为什么要使用专有编译器,而不是类似 gcc 的自由编译器?

  • ABI backwards compatibility for compiled extensions. There is some resistance to breaking that.
  • So far MSVC produces faster, smaller binaries.
  • There are some features in the code that don't compile with MinGW. They use API that MinGW does not provide headers for etc.
  • There are open questions around how we would run unit tests in a MinGW cross-compilation environment.
  • There are open questions around how well gdb works on Windows; the MSVC C++ debugger is really quite good.

使用 Visual Studio 编译64位软件

A port for 64-bit Windows is working on master with all supported compilers. To build it, use the --enable-64-bit flag to configure on versions older than LibreOffice 7.1.

已知的问题

BitDefender(比特梵德)及其他反病毒及安全工具对编译过程的破坏

If your build fails with a FileNotFoundError: such as The system cannot find the file specified: '../../../dist/out/bin\\example.exe', there's a good chance your Anti-Virus is quarantining or deleting important files.

Another potential source of problems is the sample documents (those labeled CVE) that check for known vulnerabilities to ensure they don't reappear again. In the source they are stored encrypted to avoid triggering the warnings, but when the corresponding test is run, the original is created in the temp directory and tools such as BitDefender can flag it.

If you want to run these tests, disable monitoring of the temporary build-directory <root of repo>\*\pass in your Anti-Virus tool. You will need to disable Windows Defender launch - search for and launch 'defender' from the shell.

You can also use the --disable-cve-tests autogen flag to skip the tests that are known to cause trouble.

Also note that Anti-Virus tools can slow down your build quite a bit, if you want to build fast you should disable real-time monitoring of the source tree.

Norton(诺顿)反病毒软件对编译过程的破坏

Norton Antivirus and Symantec Endpoint Protection complain about certain files that the build produces. It finds the following files (in a build without "--enable-dbgutil" )

Malware: Suspicious.Cloud
D:\bld\rel\workdir\UnpackedTarball\icu\source\bin\genrb.exe*
Malware: Suspicious.Cloud.5
D:\bld\rel\workdir\UnpackedTarball\nss\nss\lib\zlib\out\example.exe*
D:\bld\rel\workdir\UnpackedTarball\nss\dist\out\bin\example.exe* 
D:\bld\rel\instdir\program\reg4allmsdoc.dll
D:\bld\rel\instdir\program\sdqsmsi.dll
D:\bld\rel\instdir\program\sellangmsi.dll

Files with * are needed for the build - exclude them from the virus scan!

The following files appear with varying names (????) in a release build, so you cannot exclude them from the scan.

D:\bld\rel\instdir\program\RCX????.tmp
D:\bld\rel\instdir\program\RCX????.tmp
D:\bld\rel\instdir\program\RCX????.tmp

Current workaround: Don't do release builds (unless you are allowed/willing to switch off the virus scanner).

系统 PATH 路径造成的奇怪的编译损坏问题

If you experience weird build breakage that no one else seems to experience, check your PATH value and try cleaning it. Note that you need to open a new shell and re-run autogen.sh in order for the new system PATH value to take effect in your build. Some people have experienced a build failure in the shell module due to their system PATH including a path to an older OOo installation that had a DLL of the same name as the one that the build uses.

Windows 自动更新在编译时自动重启系统

Sometimes Microsoft Windows reboot during compilation. It happens because Windows Update updates operating system and reboot. To stop windows update from command line, you can enter following command in command box:

C:> net stop wuauserv

It stops a Windows Update service process.

PDF 数字签名无法通过测试

On Windows, it can happen, that PDF signing tests are failing:

[build CUT] xmlsecurity_pdfsigning
warn:sfx.appl:2956:6324:sfx2/source/appl/app.cxx:193: No DDE-Service possible. Error: 16399
warn:svl.crypto:2956:6324:svl/source/crypto/cryptosign.cxx:1415: CryptAcquireCertificatePrivateKey failed: Das Zertifikat und der private Schlüssel für die Entschlüsselung wurden nicht gefunden.
warn:vcl.filter:2956:6324:vcl/source/filter/ipdf/pdfdocument.cxx:846: PDFDocument::Sign: PDFWriter::Sign() failed
C:/Users/davido/projects/libo/xmlsecurity/qa/unit/pdfsigning/pdfsigning.cxx:174:PDFSigningTest::testPDFAdd assertion failed
- Expression: aDocument.Sign(aCertificates[0], "test", true)

Solution: Remove expired Own Certificate:

http://imgur.com/a/NdCxT

  1. Start certmgr
  2. proceed to Own Certificates
  3. Remove expired certificate
  4. Repeat the tests
  5. Done

短文件名 (8.3 文件名)

If you get an error like the following one:

configure: error: converted path "C:/PROG~1/Microsoft SDKs/Windows/v8.1A/bin/NETFX4~1.1TO/" still contains spaces. Short filenames (8.3 filenames) support was disabled on this system?
Error running configure at ./autogen.sh line 300.

Then ensure 8.3 name creation is enabled. Open the Command Prompt as administrator and run:

fsutil 8dot3name query c:

Also, check that the conflicting folder (in this case, "Microsoft SDKs") has a corresponding 8.3 filename. For example:

cd C:\Program Files (x86)\
dir /x M*

This will print a list of folders beginning with "M" and their associated 8.3 filenames. If "Microsoft SDKs" does not have a short filename, you can rename it to "tmp", then create a new folder "Microsoft SDKs", check that it has a short filename and move the contents of "tmp" to "Microsoft SDKs".

autogen.sh might report that it cannot find mscvc.exe.

This is caused by the long filename problem as well, but the solution is a bit more work:

Shift+reset, go to the safe mode, do this:

fsutil 8dot3name set c: 0
fsutil file setshortname "Program Files (x86)" PROGS
fsutil file setshortname "Microsoft Visual Studio 12.0" msvc-12
fsutil file setshortname "Windows Kits" W~Kits

Correct your PATH variable

与 MS Windows 的安全及加密有关的问题

There is a document describing various fixes for Windows Security / Crypto related problems in the Windows Server troubleshoot documentation: https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/windows-security-overview. It has a subsection for Permissions, access control, and auditing.

ALINK : 错误 AL1078: Error signing assembly -- Access is denied

Fix: the correct permissions for the MachineKey folder are described in https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/default-permissions-machinekeys-folders. A more elaborated description is in https://odetocode.com/blogs/scott/archive/2020/01/12/solving-access-denied-in-crypto-machine-keys.aspx. It's a bit complex to get right, so check twice.

Alternative workaround: open the Developer Command Prompt for VS as an administrator, and use sn tool to set `AL.EXE` to use the current user key set to sign assemblies instead of using the machine key set:

sn -m n


This modifies the following registry keys:

for 64-bit systems:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\StrongName

for 32-bit systems:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName

.NET exception occurred: System.IO.IOException: Access is denied

You may run into this error message while building the cli_uretypes module:

[build DEP] LNK:Executable/climaker.exe

[build LNK] Executable/climaker.exe
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
[build CLI] cli_uretypes
> error: .NET exception occurred: System.IO.IOException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
  at: System.Reflection.Emit.ModuleBuilder.SavePEFile(RuntimeModule module, String fileName, Int32 entryPoint, Int32 isExe, Boolean isManifestFile)
  at: System.Reflection.Emit.ModuleBuilder.Save(String fileName, Boolean isAssemblyFile, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
  at: System.Reflection.Emit.AssemblyBuilder.SaveNoLock(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
  at: System.Reflection.Emit.AssemblyBuilder.Save(String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine)
  at: ?A0x8a0098b7.sal_main()
> dying abnormally...make[1]: *** [E:/master/cli_ure/CliUnoApi_cli_uretypes.mk:14: E:/master/instdir/program/cli_uretypes.dll] Error 1
make: *** [Makefile:123: cli_ure.build] Error 2

To solve this you need to grant (as Administrator)

Modify

permission for the Users group to the folder

C:\ProgramData\Microsoft\Crypto

Unit tests failing due to Windows settings

Having Windows Display Scaling and Personalization Colors different from the defaults can make some unit tests fail. If make succeeds but make check fails and you have no local changes, try the "base" values for those settings (even if Windows recommends a different value). On Windows 10, open Settings:

  • System > Display > Scale and layout: set to 100%
  • Personalization > Colors > Choose your color: set to Light

Windows 11 has them as "Scale" and "Choose your mode".

Then retry the specific unit test or make check. After the unit tests succeed, feel free to go back to your usual settings to work on the code.

其他已知问题

  • Paths that include /opt cause problems with some external modules; it is best to avoid having your source tree in /opt; or use --disable-orcus to overcome this.
  • Asian locale builds sometimes fail due to encoding issues in the source code; in these cases, patches to fix those problems are appreciated. Alternatively, configure Windows for a US locale.

另请参考