Development/BuildingOnWindows

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

Other languages:

Selecting the host / target system

Since 114ed73a7ba56e013e6d7f886798915fb20c0946 (for more information: https://lists.freedesktop.org/archives/libreoffice/2020-September/085869.html), which basically translates to since LibreOffice 7.1, the old configure switch --enable-64-bit was dropped. To explicitly select your architecture, you have to supply the correct configure host triplet:

--host=i686-pc-cygwin: target 32-bit Intel / AMD host
--host=x86_64-pc-cygwin: target 64-bit AMD / Intel host
--host=aarch64-pc-cygwin: target 64-bit ARM host (WIP, but should run in general - see bug tdf#137143)

For all versions before LibreOffice 7.1, the default build is always 32-bit on Windows and you must explicitly call autogen.sh/configure with --enable-64-bit to get a 64-bit build.

Otherwise, your build and host system will be the same, detected by the configure script, which is probably what you want anyway.

Depending on your decision, you must install a Java version, matching the target architecture and bit count.

Example for Windows Arm64 cross-compile including Java

--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.

Build dependencies

Before you can start hacking LibreOffice on Windows, you need to follow these instructions to set up a build environment. Do also read our generic building hints.

Install Visual Studio

You need the Microsoft compiler/development suite Visual Studio, which can be obtained from here: https://visualstudio.microsoft.com/downloads/

There is an edition that is free of charge, the Community Edition, that includes everything needed to build all LibreOffice features: https://visualstudio.microsoft.com/vs/community/

Current master (since LibreOffice 7.0) requires Visual Studio 2019 (at least v16.5) (or the equivalent Visual Studio Build Tools).

Since VS 2017, a separate Build Tools package is available that includes compilers, and most toolchains and libraries without installing Visual Studio IDE: https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2019. Note that this option excludes convenient/efficient debugging experience.

For older LibreOffice versions the required Visual Studio versions are:

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

Visual Studio 2019 can optionally install 2017 and 2015 compilers (VS 2015 / 2017 C++ Buildtools). The only thing missing are the older C++ Redistributable MSM packages, so older configure.ac scripts need a little patch to build MSI packages.

Older Visual Studio versions are available at https://visualstudio.microsoft.com/vs/older-downloads/

Visual Studio (and Visual Studio Build Tools) 2019 at least v16.5 works on the current master. Select the Desktop development with C++ workload and check that all of the following components (which are enough for the build) are selected individually:

MSVC v14x - VS 20xx C++ x64/x86 build tools (Latest)
C++ core desktop features
Windows 10 (or 11) SDK (10.0.xxxxx.x), with SDK version > 10.0.20*
Windows Universal C Runtime
C++ ATL for v14x build tools (x86 & x64)
.NET Framework 4.x SDK (.NET Framework 5.x SDK and later are currently not supported. These don't register their information to registry, don't have csc.exe and they use dotnet command with csc.dll instead for compiling.)
C++ 20xx Redistributable MSMs (only required to build MSI installer)
C++ Clang Compiler for Windows (x.x.x)

If you want to cross-build for ARM64, you have to select the following additional components:

MSVC v142 - VS 20xx C++ ARM64 build tools (v14.2x)
C++ ATL for v142 build tools (ARM64)

You can select these options in the VS installer.

The redistributable MSMs (only required to build MSI installer) are not part of the workload selection in 2019 and later, but need to be picked from the individual component selection. For details, see the comments to the VS Developer Community questions Where MergeModules for 14.20.27404.0 and 14.20.27508? and Deprecation of CRT redist MSMs?.

Note:
Visual Studio command-line tools use system OEM codepage to output messages to console, when corresponding UI language is installed as part of Visual Studio installation. The OEM codepage on Windows depends on system locale defined using "Language for non-Unicode programs" in intl.cpl applet (description of the setting), and is often incompatible with encoding set in cygwin shell (typically UTF-8). This garbles the output from the tools in the build log.
You might want to make sure that you only install English UI when installing Visual Studio to avoid that problem.

Install Java

No matter what version of Visual Studio you're using, you need a

Java Development Kit (JDK) Version 17 or later (see [1]). Make sure to get a 32-bit SDK if you are building for 32-bit Windows, and a 64-bit SDK if you are building for 64-bit Windows. Grab Temurin from adoptium.net, JDK from oracle.com (Oracle requires login to download), or OpenJDK from microsoft.com (Microsoft build of OpenJDK does not require login).

Note that the Oracle JDK is 64-bit only.

Note that the Temurin installation will not be detected out of the box: you need to manually enable the "JavaSoft (Oracle) registry keys" option for this.

In your autogen.input file, point to the path in this way: --with-jdk-home=C:/Program Files/... (don't point to its bin subdirectory, only to the parent directory, like --with-jdk-home=C:/Program Files/Eclipse Adoptium/jdk-21.0.1.12-hotspot).

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>.

Install Cygwin and other dependencies

Note:
The Easiest way to perform the following is to use LODE , which automates all that is necessary, beyond installing Visual Studio and Java.

If you want to do it the hard way, continue reading.

Install Cygwin Requirements

On Windows, you must install Cygwin from www.cygwin.com. The latest Cygwin version should work fine. The version can be checked by invoking uname -a command.

The easiest way to do so is to download Cygwin's setup-x86.exe (32-bit) or setup-x86_64.exe (64-bit).

It is preferable to use 64-bit Cygwin if possible because it is less likely to have problems with fork() (see Cygwin FAQ for details).

This instruction uses the 64-bit version as an example: Run cmd and navigate to the download dir (if you have trouble navigating, you can also drag setup-x86_64.exe from the file explorer into the cmd window) and copy and paste the command below to run setup-x86_64.exe with the list of required packages preselected.

  setup-x86_64.exe -P autoconf -P automake -P bison -P cabextract -P doxygen -P flex -P gcc-g++ ^
                -P gettext-devel -P git -P gnupg -P gperf -P make -P mintty ^
                -P nasm -P openssh -P openssl -P patch -P perl -P python -P python3 ^
                -P pkg-config -P rsync -P unzip -P vim -P wget -P zip -P perl-Archive-Zip ^
                -P perl-Font-TTF -P perl-IO-String

This launches the GUI and requires you to manually choose installation paths etc, but the packages passed via command line are pre-selected meaning you just need to accept the selection.

NOTE: installation path of Cygwin must not contain non-ASCII letters to avoid autogen.sh/configure problems (if it contains, moves the folder of the Cygwin installation to a new place and update its Windows shortcuts & Start Menu items).

Alternatively, run the setup-x86.exe or setup-x86_64.exe utility, switch the package view mode to 'Full' by pressing 'View' until 'Full' is displayed beside it, then manually select the packages listed in the above command for installation.

If you upgraded Cygwin, you might have to run the rebaseall command (not needed if you installed Cygwin for the first time):

Close all Cygwin consoles, run c:\cygwin\bin\dash.exe and in the terminal, launch /bin/rebaseall.

Other dependencies

After having installed Cygwin, open Cygwin command line by clicking on its desktop icon Cygwin64 Terminal, and perform next steps:

Install GNU Make

A Win32 build of GNU Make 4.0+ is made available (and required) for building LibreOffice.

It's easiest to put it in /opt/lo/bin, where configure will automatically find it; you can also use another location and set the MAKE variable. Either prepend /opt/lo/bin to PATH, or alternatively, when you build LibreOffice, always invoke "make" with the absolute path /opt/lo/bin/make (or wherever you put it). LibreOffice can not and should not use Cygwin's /usr/bin/make.

mkdir -p /opt/lo/bin
cd /opt/lo/bin
wget https://dev-www.libreoffice.org/bin/cygwin/make-4.2.1-msvc.exe
cp make-4.2.1-msvc.exe make
chmod +x make

Install ant and junit

You can extract them anywhere, they don't have to be installed. If you don't want to use Junit, it can be disabled with --without-junit in the autogen.sh command later.

mkdir -p c:/sources
cd c:/sources
wget https://archive.apache.org/dist/ant/binaries/apache-ant-1.9.5-bin.tar.bz2
tar -xjvf apache-ant-1.9.5-bin.tar.bz2
wget http://downloads.sourceforge.net/project/junit/junit/4.10/junit-4.10.jar

Also works with the combination of junit 4.13,hamcrest 2.2 and Apache Ant 1.10.12

Clone the LibreOffice source code repositories

NOTE: sources should be in a relatively short path to avoid exceeding the file/pathname limit and the destination path cannot have any space in it.

cd c:/sources
git clone https://gerrit.libreoffice.org/core libo-core

Optionally create build directory

You can build LibreOffice into another directory than your checkout. This helps keep the source code tree clean and eases building multiple versions.

If you want to build into a separate directory, say c:/build, enter these commands:

mkdir c:/build
cd c:/build

Otherwise change directory to the c:/sources/libo-core folder:

cd c:/sources/libo-core

Configure and build the code

Now run autogen.sh to configure the build:

c:/sources/libo-core/autogen.sh \
             --with-external-tar=c:/sources/lo-externalsrc \
             --with-junit=c:/sources/junit-4.10.jar \
             --with-ant-home=c:/sources/apache-ant-1.9.5 \
             --enable-pch --disable-ccache \
             [additional switches, if you know what you are doing :-) ...]

Note that if you have installed ccache from Cygwin environment, it is recommended that you disable it with --disable-ccache as in the command above, because it does not provide noticeable improvement in speed. On the other hand, you can use VS builds of ccache, which provide good speed up. But please avoid mixing ccache and PCH on Windows, as the build may fail when mixing these two.

If the autogen.sh script complains that it cannot find some header files, it is possible that it cannot locate your Windows SDK or that it finds a corrupted one. This may happen if you installed multiple versions of Visual Studio on your computer, especially if you installed a Beta version, and even if you uninstalled those. In this case, you may use the --with-windows-sdk=7.1A, possibly replacing 7.1A with another version of the SDK to select a specific uncorrupted version.

Also, configure.ac used by autoconf internally gives -showIncludes to cl.exe in order to get what prefix is used by the cl.exe for each included header. When the command is run, it may fail to find vcruntime.h used by stdlib.h. Visual Studio users normally use developer console when they use the cl command, where vcvarsall.bat is called to set necessary environment variables, which may be missing when using autoconf.

Save a copy of the last used parameters in the file autogen.input. It will not be overridden by autogen.sh when using other parameters. If autogen.sh is called again without parameters, it will fetch its input from autogen.input if it is present.

At this point, you might want to consider additional options to pass to autogen with

$ ./autogen.sh --help

For example consider adding a Debugging option. Changing some of these options will require to do a full rebuild: e.g., adding --enable-dbgutil. Since the following command make takes a vast quantity of time to run for the first time, you probably would like to save time by specifying the settings you'd need depending on the ultimate goal of your build. In case of doubt, possibly it's good to ask for advice on #libreoffice-dev.

Read the summary output from the autogen.sh command. If it did not report any errors or relevant warnings, then all that is left to do is to run the right version of make to build LibreOffice. Before you do this, make sure your anti-virus software will not cause any problems.

/opt/lo/bin/make gb_COLOR=1  # gb_COLOR=1 enables colored output

Run LibreOffice

When the build has finished without errors, you can run your fresh build of LibreOffice using

instdir/program/soffice.exe

Microsoft Visual Studio Project Integration

The LibreOffice build system can generate project files for some IDEs including -- thanks to Honza Havlíček's excellent work -- Microsoft Visual Studio: (note that this does not allow a full build so you still need to use Cygwin to do full builds)

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

YouTube privacy policy

Build a project file for Visual Studio

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

$ /opt/lo/bin/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.

Why MSVC?

It is a frequently asked question, usually coming from free software purists, why we use proprietary compiler instead of a free one (i.e. 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.

Autogen options

Something like the following in the autogen.input file is known to produce a working build:

--disable-odk
--with-junit=c:/sources/junit-4.10.jar
--with-ant-home=c:/sources/apache-ant-1.9.5

Of course, change the information behind ='s to fit your needs; set the paths to what you have used when installing various prerequisites.

You also need to specify the path for ant with --with-ant-home=<cygwin path of ant>.

64-bit Visual Studio build

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.

Notes on older and non-default MS compilers

Switching to non-default compiler

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

If you want to use Visual Studio 2022, you have to say it explicitly:

--with-visual-studio=2022

Running Glade on Windows

To edit dialogs (.ui files), you need Glade. There is an old version for Windows but it doesn't support all properties that are needed for LibreOffice dialogs.

So you need to install Glade in Cygwin:

Install Glade in Cygwin by running the Cygwin setup, then install the following packages:

xorg-server, glade, dbus

You may have to invoke:

 dbus-uuidgen > /etc/machine-id

Add this to your .bashrc:

export GLADE_CATALOG_SEARCH_PATH=<path_to_core>/instdir/share/glade

Open one Cygwin console and run:

X -multiwindow

Open another Cygwin console and run:

DISPLAY=:0.0 glade

That's it, you should now run Glade ≥ 3.18

Glade 3.20.3 on Windows 10, editing svx/uiconfig/ui/addmodeldialog.ui

Known Problems

Cygwin and git

The main problem is the cygwin-git is very slow.

The alternatives are:

Install the win-git from here: https://gitforwindows.org/ (This installs a "Git-Bash Here" in Explorer)
Use Windows Subsystem for Linux (WSL) to install a Linux distribution (see e.g. https://www.sitepoint.com/wsl2-windows-terminal/ for how to install distribution and optionally Windows Terminal)

Here are the times using the same computer and repo and not being the first call:

git status

git	Version	Time [sec]
cygwin	2.21.0	20
win	2.22.0	1
WSL	2.16.0	6

Git in WSL is slower than git-bash, but it has the advantage of working in a complete Linux environment with all other tools provided by the distribution. You should not mix tools from Cygwin and WSL (i.e. open separate terminals for Cygwin and for WSL).

NOTE: A mix between different git tools is not always compatible, when you change you should renew (clone) the git repositories.

Best to configure "autocrlf" before cloning master, to avoid the problem (see below for how to set "autocrlf" to a sensible value)

Executable permission on files

It is desirable to use filemode = false in the [core] section of .git/config, to avoid all files having executable permission in cygwin-git. This setting allows Git to ignore the differences between file modes of files on disk and in index, which is useful with cygwin-git, which sees all files on disk as having executable permission (755 instead of typical 644). However, sometimes you need to add a script file with executable permission, and with the mentioned setting, you would need to use an explicit command to set the permission to the added file:

  git update-index --chmod=+x myfile.sh

Ref: git-update-index documentation.

Cygwin Shell

You will use Cygwin Bash Shell for the whole build process. You must install all the build dependencies above before starting the shell to run autogen because autogen needs some environment variables to find the tools.

If you see an error similar to the following when running autogen.sh

   $'\r': command not found

This means that Windows style newline characters are creating issues with the Cygwin Shell. Unfortunately, the default mode for Git for Windows is automatically changing line endings on file checkout. A good way to solve this is to configure git to clone without changing line ending. To do so, give the following command in Cygwin Shell:

   git config core.autocrlf false

Big List Of Dodgy Apps

If you get mysterious build breaks, the building is very slow or your systems hang totally, check if you are running an application that interferes with Cygwin. For a list of known offenders, see this point in the Cygwin FAQ.

BitDefender / other Anti-Virus / security tools breaking the build

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-directories <root of repo>\*\pass and C:\cygwin\tmp in your Anti-Virus tool. For Windows 8 and 10 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 and the temporary files directory C:\cygwin\tmp.

Norton Antivirus breaking the build

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).

System PATH causing weird build breakage

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 Update automatically reboot during compilation

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.

Failing PDF signing tests

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

Start certmgr
proceed to Own Certificates
Remove expired certificate
Repeat the tests
Done

Short filenames (8.3 filenames)

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".

When choosing a directory in which to install LODE, please use the 8.3 rules. Windows does not correct environment variables, therefore e.g. LODE_HOME will be wrong and will cause problems. Therefore, always clone lode in an 8.3 path such as:

C:\source\LO\lode

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 Security / Crypto related problems

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 : error 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

See this stack overflow question and mail thread starting from this message for more information.

.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

Using a Windows program as your git editor

Paths under Cygwin are an endless source of nightmares. This section documents using Notepad++ as your git editor under Cygwin. It assumes you are using the 64-bit version of Notepad++ (adjust the path, if using the 32-bit version).

Below you will find a wrapper script written by Gene Pavlovsky (original gist in GitHub).

Save the script as cygrun.sh into the bin directory in Cygwin's root (so it is in the PATH). When saving the cygrun.sh using Notepad++, do this first to make sure it has Unix line endings: from the "Edit" menu, select "EOL Conversion" -> "UNIX (LF)".
In a Cygwin shell inside the bin directory, give this command to create a symbolic link:
```
ln -s cygrun.sh cygrun
```
Give this command in your home directory:
```
git config core.editor "cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
```
or alternatively edit your .gitconfig to contain this editor block:
```
editor = cygrun -w 'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin
```
The extra parameters have Notepad++ open a new window and block the calling process until it is closed, so that git receives the edited commit comment.

Bonus: if you want to define Notepad++ as the default editor of your shell and also access it through a handy "np" alias, add these to the .bashrc file in your home directory:

export EDITOR="'c:/Program Files/Notepad++/notepad++.exe'"
alias np="'c:/Program Files/Notepad++/notepad++.exe'"

Remember to be very careful with the line endings, when creating new files and use the Edit -> EOL Conversion.

The cygrun script:

#!/bin/bash
#
# Run a program, converting UNIX and Windows format path arguments.
#
# Install in Cygwin's `bin` dir or elsewhere in your path. 
# Create a symlink for convenience: `ln -s cygrun.sh cygrun`.
#
# Use `cygrun -w windows-program unix-path ...` to run Windows programs (e.g. from UNIX software).
# E.g., in my .gitconfig core.editor is set to `cygrun -w 'C:/Program Files/Notepad2/Notepad2.exe'`.
#
# Use `cygrun [-u] unix-program windows-path ...` to run Cygwin programs (e.g. from Windows software).
# Usually not needed since Cygwin translates Windows paths automatically (e.g. `ls 'C:\Windows'` works).
# Still it can be useful in case a Windows program might produce paths that mix backslashes and forward slashes,
# e.g. in Apache Ant `${dist.dir}/file` evaluates to `C:\path\to\project\dist/file`, which Cygwin won't
# translate automatically. So, to deploy the file, I use `cygrun -u scp ${dist.dir}/file ${deploy.url}`.
#
# Use the `-b` option to detach from tty, run the process in background, and return immediately.
#
# There is currently a limitation on passing non-path arguments to a program. Since there is no way
# to automatically distinguish path arguments from non-path arguments, all of the arguments are passed
# to `cygpath`. As long as non-path arguments don't contain `/` or `\` characters, and `-a` or `-C`
# options are not used, `cygpath` will return the arguments unmodified - no problem.
# Due to this, the `-a` and `-C` options are disabled at the moment.
# TODO: Add an option allowing to specify index positions of path arguments (comma-separated, support ranges).
#
# Most of the options are passed as is to `cygpath`, which is used for path conversion.

set -e -o pipefail

usage() {
  local code=${1:-2}
  test $code -ne 0 && exec >&2
  
  echo "Usage: $(basename "$0" .sh) [options] program [argument]..."
  echo
  echo 'Run a program, converting UNIX and Windows format path arguments.'
  echo
  echo 'Output type options:'
  echo
  echo '  -d, --dos             print DOS (short) form of NAMEs (C:\PROGRA~1\)'
  echo '  -m, --mixed           like --windows, but with regular slashes (C:/WINNT)'
  echo '  -u, --unix            (default) print Unix form of NAMEs (/cygdrive/c/winnt)'
  echo '  -w, --windows         print Windows form of NAMEs (C:\WINNT)'
  echo
  echo 'Path conversion options:' 
  echo
  echo '  -U, --proc-cygdrive   Emit /proc/cygdrive path instead of cygdrive prefix'
  echo '                        when converting Windows path to UNIX path.'
  echo '  -c, --codepage CP     print DOS, Windows, or mixed pathname in Windows'
  echo '                        codepage CP.  CP can be a numeric codepage identifier,'
  echo '                        or one of the reserved words ANSI, OEM, or UTF8.'
  echo '                        If this option is missing, cygrun defaults to the'
  echo '                        character set defined by the current locale.'
  echo
  echo "Other 'cygpath' options:"
  echo
  echo '  -f, --file FILE       read FILE for input; use - to read from STDIN'
  echo "  -o, --option          read 'cygpath' options from FILE as well (for use with --file)"
  echo '  -h, --help            output usage information and exit'
  echo
  echo 'Run options:'
  echo
  echo '  -b, --background      run in a new session'
  echo '  -n, --dry-run         print the command that would be executed, and exit'
  
  exit $code
}

run() {
  local -n _run_args=$2
  if test "$dry_run"; then
    test "$chdir" && printf 'cd %s\n' "$chdir"
    printf '%s\n' "$1 ${_run_args[*]}"
  else
    test "$chdir" && cd -- "$chdir"
    if test "$background"; then
      setsid "$1" "${_run_args[@]}" </dev/null &>/dev/null &
    else
      exec "$1" "${_run_args[@]}"
    fi
  fi
}

declare opts fileopts chdir background dry_run
while test $# -gt 0; do
  case $1 in
    -d|--dos|-u|--unix|-m|--mixed|-w|--windows|-U|--proc-cygdrive|-o|--option)
      opts="${opts} $1"
    ;;
    -C|--codepage|-f|--file)
      opts="${opts} $1 $2"
      shift
    ;;
    -f|--file)
      fileopts=1
      opts="${opts} -i $1 $2"
      shift
    ;;
    -b|--background)
      background=1
    ;;
    -n|--dry-run)
      dry_run=1
    ;;
    -h|--help)
      usage 0
    ;;
    --)
      shift
      break
    ;;
    -*)
      script="$(basename "$0" .sh)"
      echo "$script: Unknown option: $1" >&2
      echo "Try '$script --help' for more information." >&2
      exit 2
    ;;
    *)
      break
    ;;
  esac
  shift
done
test "$chdir" && opts="$opts -a"

program=$1
test "$program" || usage
shift

declare -a args
test $# -gt 0 -o "$fileopts" && mapfile -t args < <(cygpath $opts -- "$@" || exit 1)
run "$program" args