Windows 64 bit (aka x64 aka AMD64 aka 64-bit)

From The Document Foundation Wiki
Jump to navigation Jump to search

LibreOffice x64 is UP AND RUNNING:

This page describes the process of building LibreOffice on Windows targeting x86_64 (aka x64 aka AMD64 aka 64-bit) architecture.


TDF releases available since LibreOffice 5.0 (listed as “Windows x86_64 (Vista or newer required)”).


Daily builds on this platform can be downloaded from one of these Tinderboxes:

Ongoing efforts to build gpgme on Windows


Build works, pending change:


Build works, pending change:


Build works, pending change: Linking is failing to resolve symbols:

It seems that even though libgpg-error and libassua are correctly passed and detcted by the configuration script, it still doesn work:

 *** Warning: This system can not link to static lib archive C:/Users/davido/projects/libo/workdir/UnpackedTarball/libassuan/src/.libs/
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have.
 *** Warning: This system can not link to static lib archive C:/Users/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs/
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have.
 libtool: link: C:/Users/davido/projects/libo/workdir/LinkTarget/Executable/gcc-wrapper.exe -o .libs/libgpgme-11.dll  .libs/conversion.obj .libs/b64dec.obj .libs/get-env.obj .libs/parsetlv.obj .libs/mbox-util.obj .libs/data.obj .libs/data-fd.obj .libs/data-stream.obj .libs/data-mem.obj .libs/data-user.obj .libs/data-compat.obj .libs/data-identify.obj .libs/signers.obj .libs/sig-notation.obj .libs/wait.obj .libs/wait-global.obj .libs/wait-private.obj .libs/wait-user.obj .libs/op-support.obj .libs/encrypt.obj .libs/encrypt-sign.obj .libs/decrypt.obj .libs/decrypt-verify.obj .libs/verify.obj .libs/sign.obj .libs/passphrase.obj .libs/progress.obj .libs/key.obj .libs/keylist.obj .libs/keysign.obj .libs/trust-item.obj .libs/trustlist.obj .libs/tofupolicy.obj .libs/import.obj .libs/export.obj .libs/genkey.obj .libs/delete.obj .libs/edit.obj .libs/getauditlog.obj .libs/opassuan.obj .libs/passwd.obj .libs/spawn.obj .libs/assuan-support.obj .libs/engine.obj .libs/engine-gpg.obj .libs/status-table.obj .libs/engine-gpgsm.obj .libs/engine-assuan.obj .libs/engine-gpgconf.obj .libs/engine-g13.obj .libs/vfs-mount.obj .libs/vfs-create.obj .libs/engine-spawn.obj .libs/gpgconf.obj .libs/queryswdb.obj .libs/w32-util.obj .libs/dirinfo.obj .libs/debug.obj .libs/gpgme.obj .libs/version.obj .libs/error.obj .libs/ath.obj .libs/w32-io.obj .libs/versioninfo.obj .libs/ttyname_r.obj .libs/stpcpy.obj .libs/setenv.obj    -Od -FS -static-libgcc   `func_echo_all " -LC:/Users/davido/projects/libo/workdir/UnpackedTarball/libassuan/src/.libs -LC:/USers/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs -LC:/USers/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs/.libs -LC:/Users/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs" | /usr/bin/sed 's/ -lc$//'` -link -dll
 ARGS=  -nologo -EHsc -MDd -Gy -Ob1 -Oxs -Oy-  .libs/conversion.obj .libs/b64dec.obj .libs/get-env.obj .libs/parsetlv.obj .libs/mbox-util.obj .libs/data.obj .libs/data-fd.obj .libs/data-stream.obj .libs/data-mem.obj .libs/data-user.obj .libs/data-compat.obj .libs/data-identify.obj .libs/signers.obj .libs/sig-notation.obj .libs/wait.obj .libs/wait-global.obj .libs/wait-private.obj .libs/wait-user.obj .libs/op-support.obj .libs/encrypt.obj .libs/encrypt-sign.obj .libs/decrypt.obj .libs/decrypt-verify.obj .libs/verify.obj .libs/sign.obj .libs/passphrase.obj .libs/progress.obj .libs/key.obj .libs/keylist.obj .libs/keysign.obj .libs/trust-item.obj .libs/trustlist.obj .libs/tofupolicy.obj .libs/import.obj .libs/export.obj .libs/genkey.obj .libs/delete.obj .libs/edit.obj .libs/getauditlog.obj .libs/opassuan.obj .libs/passwd.obj .libs/spawn.obj .libs/assuan-support.obj .libs/engine.obj .libs/engine-gpg.obj .libs/status-table.obj .libs/engine-gpgsm.obj .libs/engine-assuan.obj .libs/engine-gpgconf.obj .libs/engine-g13.obj .libs/vfs-mount.obj .libs/vfs-create.obj .libs/engine-spawn.obj .libs/gpgconf.obj .libs/queryswdb.obj .libs/w32-util.obj .libs/dirinfo.obj .libs/debug.obj .libs/gpgme.obj .libs/version.obj .libs/error.obj .libs/ath.obj .libs/w32-io.obj .libs/versioninfo.obj .libs/ttyname_r.obj .libs/stpcpy.obj .libs/setenv.obj -Od -FS -static-libgcc     -link -dll -link -dll -out:.libs/libgpgme-11.dll -LIBPATH:C:/Users/davido/projects/libo/workdir/UnpackedTarball/libassuan/src/.libs -LIBPATH:C:/USers/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs -LIBPATH:C:/USers/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs/.libs -LIBPATH:C:/Users/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs
 CMD= C:\PROGRA~2\MICROS~1\2017\COMMUN~1\VC\Tools\MSVC\1411~1.255\bin\HostX64\x64\cl.exe  -nologo -EHsc -MDd -Gy -Ob1 -Oxs -Oy-  .libs/conversion.obj .libs/b64dec.obj .libs/get-env.obj .libs/parsetlv.obj .libs/mbox-util.obj .libs/data.obj .libs/data-fd.obj .libs/data-stream.obj .libs/data-mem.obj .libs/data-user.obj .libs/data-compat.obj .libs/data-identify.obj .libs/signers.obj .libs/sig-notation.obj .libs/wait.obj .libs/wait-global.obj .libs/wait-private.obj .libs/wait-user.obj .libs/op-support.obj .libs/encrypt.obj .libs/encrypt-sign.obj .libs/decrypt.obj .libs/decrypt-verify.obj .libs/verify.obj .libs/sign.obj .libs/passphrase.obj .libs/progress.obj .libs/key.obj .libs/keylist.obj .libs/keysign.obj .libs/trust-item.obj .libs/trustlist.obj .libs/tofupolicy.obj .libs/import.obj .libs/export.obj .libs/genkey.obj .libs/delete.obj .libs/edit.obj .libs/getauditlog.obj .libs/opassuan.obj .libs/passwd.obj .libs/spawn.obj .libs/assuan-support.obj .libs/engine.obj .libs/engine-gpg.obj .libs/status-table.obj .libs/engine-gpgsm.obj .libs/engine-assuan.obj .libs/engine-gpgconf.obj .libs/engine-g13.obj .libs/vfs-mount.obj .libs/vfs-create.obj .libs/engine-spawn.obj .libs/gpgconf.obj .libs/queryswdb.obj .libs/w32-util.obj .libs/dirinfo.obj .libs/debug.obj .libs/gpgme.obj .libs/version.obj .libs/error.obj .libs/ath.obj .libs/w32-io.obj .libs/versioninfo.obj .libs/ttyname_r.obj .libs/stpcpy.obj .libs/setenv.obj -Od -FS -static-libgcc     -link -dll -link -dll -out:.libs/libgpgme-11.dll -LIBPATH:C:/Users/davido/projects/libo/workdir/UnpackedTarball/libassuan/src/.libs -LIBPATH:C:/USers/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs -LIBPATH:C:/USers/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs/.libs -LIBPATH:C:/Users/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs

So that libtool is dropping the libgpg-error and libassuan libraries.

If I link them manually:

 cl.exe  -nologo -EHsc -MDd -Gy -Ob1 -Oxs -Oy-  .libs/conversion.obj .libs/b64dec.obj .libs/get-env.obj .libs/parsetlv.obj .libs/mbox-util.obj .libs/data.obj .libs/data-fd.obj .libs/data-stream.obj .libs/data-mem.obj .libs/data-user.obj .libs/data-compat.obj .libs/data-identify.obj .libs/signers.obj .libs/sig-notation.obj .libs/wait.obj .libs/wait-global.obj .libs/wait-private.obj .libs/wait-user.obj .libs/op-support.obj .libs/encrypt.obj .libs/encrypt-sign.obj .libs/decrypt.obj .libs/decrypt-verify.obj .libs/verify.obj .libs/sign.obj .libs/passphrase.obj .libs/progress.obj .libs/key.obj .libs/keylist.obj .libs/keysign.obj .libs/trust-item.obj .libs/trustlist.obj .libs/tofupolicy.obj .libs/import.obj .libs/export.obj .libs/genkey.obj .libs/delete.obj .libs/edit.obj .libs/getauditlog.obj .libs/opassuan.obj .libs/passwd.obj .libs/spawn.obj .libs/assuan-support.obj .libs/engine.obj .libs/engine-gpg.obj .libs/status-table.obj .libs/engine-gpgsm.obj .libs/engine-assuan.obj .libs/engine-gpgconf.obj .libs/engine-g13.obj .libs/vfs-mount.obj .libs/vfs-create.obj .libs/engine-spawn.obj .libs/gpgconf.obj .libs/queryswdb.obj .libs/w32-util.obj .libs/dirinfo.obj .libs/debug.obj .libs/gpgme.obj .libs/version.obj .libs/error.obj .libs/ath.obj .libs/w32-io.obj .libs/versioninfo.obj .libs/ttyname_r.obj .libs/stpcpy.obj .libs/setenv.obj -Ox -FS -link -dll -out:.libs/libgpgme-11.dll -LIBPATH:C:/Users/davido/projects/libo/workdir/UnpackedTarball/libassuan/src/.libs -LIBPATH:C:/Users/davido/projects/libo/workdir/UnpackedTarball/libgpg-error/src/.libs libassuan.lib libgpg-error.lib advapi32.lib shell32.lib ole32.lib uuid.lib comctl32.lib kernel32.lib ws2_32.lib user32.lib

then it just works. I have uploaded the DLL here:

Ongoing efforts to support MSVC 15.3 (aka VS 2017 Update 3)


64bit mode and 32bit modes, both debug and release modes are known to work.

Ongoing efforts to support MSVC 14.0 (aka VS 2015)


64bit mode and 32bit modes, both debug and release modes are known to work.

VC Runtime Install Error (FIXED, keep for ref)

  • VC Runtime libraries are installed in wrong directory (redist libraries for MSVC 14.0)

Old problem that appear to be unrelated: original merge module 64 bit was broken: - here MS claims that since VS 2015 U1, the merge modules for 64-bit runtime are fixed here is a hack is provided with Orca how to "fix" merge module

Even after MSVC 14.0 Upgrade 3 installation, and building LO, installing the msi package refuses to start unless vc2015_redist package is installed separately.

There are two workarounds:

  1. install MSVC 14.0 Redistributable manually:
  2. patch C:\Program Files (x86)\Common Files\Merge Modules\Microsoft_VC140_CRT_x64.msm before building LO:

Open the merge module Microsoft_VC140_CRT_x64.msm with an editor, and replace two lines in "Directory" section:

 System64Folder.363ED482_721F_3A34_85B3_A96CD936D64F: TARGETDIR
 System64Folder_amd64_VC.363ED482_721F_3A34_85B3_A96CD936D64F: System64Folder.363ED482_721F_3A34_85B3_A96CD936D64F


 System64Folder: TARGETDIR
 System64Folder_amd64_VC.363ED482_721F_3A34_85B3_A96CD936D64F: System64Folder

This is exactly the content of MSVC 12 merge module, where the installation of VC redist libraries works as expected. After this hack, the produced LO msi package would install the libraries in C:\Windows\System32 and *not* in C:\System64:

 MSI (s) (F4:74) [18:30:00:559]: Executing op: ComponentRegister(ComponentId={B33258FD-750C-3B42-8BE4-535B48E97DB4},KeyPath=C:\Windows\system32\vcruntime140.dll,State=3,,Disk=1,SharedDllRefCount=3,BinaryType=1)
 1: {6DD74107-1FF4-499D-B0AB-151B67E2612D} 2: {B33258FD-750C-3B42-8BE4-535B48E97DB4} 3: C:\Windows\system32\vcruntime140.dll 
 MSI (s) (F4:74) [18:30:00:559]: Executing op: ComponentRegister(ComponentId={22824972-0C4A-31B4-AEEF-9FC7596F1305},KeyPath=C:\Windows\system32\msvcp140.dll,State=3,,Disk=1,SharedDllRefCount=3,BinaryType=1)
 1: {6DD74107-1FF4-499D-B0AB-151B67E2612D} 2: {22824972-0C4A-31B4-AEEF-9FC7596F1305} 3: C:\Windows\system32\msvcp140.dll 
 MSI (s) (F4:74) [18:30:00:559]: Executing op: ComponentRegister(ComponentId={35B5C1D2-EB5B-3569-83EB-78E34F5C3254},KeyPath=C:\Windows\system32\concrt140.dll,State=3,,Disk=1,SharedDllRefCount=3,BinaryType=1)
 1: {6DD74107-1FF4-499D-B0AB-151B67E2612D} 2: {35B5C1D2-EB5B-3569-83EB-78E34F5C3254} 3: C:\Windows\system32\concrt140.dll 
 MSI (s) (F4:74) [18:30:00:559]: Executing op: ComponentRegister(ComponentId={D227D7DF-D9F8-33AF-B935-4BF2F47F2EA4},KeyPath=C:\Windows\system32\vccorlib140.dll,State=3,,Disk=1,SharedDllRefCount=3,BinaryType=1)
 1: {6DD74107-1FF4-499D-B0AB-151B67E2612D} 2: {D227D7DF-D9F8-33AF-B935-4BF2F47F2EA4} 3: C:\Windows\system32\vccorlib140.dll

Looking what WiX toolset has to say on CRT merge module problem

This is the dummy WiX installer project: Building this WiX project with Visual Studio 2015 and installing the resultng MSI reveals no problem: CRT DLLs are all installed in correct directory for x64 bit system: C:\Windows\System32 WiX toolset contains dark.exe utilitiy to decompile the MSI:


Converts a Windows Installer database into a set of WiX source files. This tool is very useful for getting all your authoring into a WiX source file when you have an existing Windows Installer database. However, you will then need to tweak this file to accomodate different languages and breaking things into fragments.

When i do it for the working MSM => MSI i get the WiX source file:

Even better, WiX toolset contains melt.exe utility, that is able to decompile merge module and convert it to WiX soure file:


Converts an .msm into a component group in a WiX source file.

Feeding melt.exe with Microsoft_vc140_CRT_X64.msm we get this WiX source description:

So, clearly we are losing these two lines:

 <CustomAction Id="System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1" Property="System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1" Value="[System64Folder]" />
 <CustomAction Id="System64Folder_amd64_VC.3CFBED52_9B44_3A4D_953C_90E456671BA1" Property="System64Folder_amd64_VC.3CFBED52_9B44_3A4D_953C_90E456671BA1" Value="[System64Folder]" />

The mistery is, in original msm module, the custom action table is empty:

 Action	Type	Source	Target	ExtendedType
 s72	i2	S72	S255	I4
 CustomAction	Action

After merging CRT MSM into msi with WiX, and exporting the tables for the resulting MSI, suddenly this custom action table content appears:

 Action	Type	Source	Target	ExtendedType
 s72	i2	S72	S255	I4
 CustomAction	Action
 System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1	51	System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1	[System64Folder]	
 System64Folder_amd64_VC.3CFBED52_9B44_3A4D_953C_90E456671BA1	51	System64Folder_amd64_VC.3CFBED52_9B44_3A4D_953C_90E456671BA1	[System64Folder]

Interestingly, very similar problem was reported in WiX User Mailing list for earlier versions of VS 2015 compilers/merge modules:

The same report was later forwarded to the MS knowledge base as:

And was later reported as has been fixed.

Why CustomAction and InstallExecuteSequence for setting directory name property is correctly added in WiX toolset?


  • Set up WiX3
  • Build it
  • Debug session melt decompiler with this parameters: Microsoft_VC140_CRT_x64.msm Microsoft_VC140_CRT_x64.wxs

After decompiling, the directory table is walked down, and each and every directory name is compared if it starts with (StartsWith) a known standard directory names, namely:


With this code path:

	wix.dll!Microsoft.Tools.WindowsInstallerXml.Melter.StartsWithStandardDirectoryId(string directoryId, out string standardDirectoryId) Line 304	C#
	wix.dll!Microsoft.Tools.WindowsInstallerXml.Melter.WalkDirectory(Microsoft.Tools.WindowsInstallerXml.Serialize.Directory directory) Line 242	C#
	wix.dll!Microsoft.Tools.WindowsInstallerXml.Melter.WalkDirectory(Microsoft.Tools.WindowsInstallerXml.Serialize.Directory directory) Line 256	C#
	wix.dll!Microsoft.Tools.WindowsInstallerXml.Melter.ConvertModule(Microsoft.Tools.WindowsInstallerXml.Serialize.Wix wix) Line 121	C#
	wix.dll!Microsoft.Tools.WindowsInstallerXml.Melter.Melt(Microsoft.Tools.WindowsInstallerXml.Output wixout) Line 100	C#
	melt.exe!Microsoft.Tools.WindowsInstallerXml.Tools.Melt.MeltModule() Line 182	C#
	melt.exe!Microsoft.Tools.WindowsInstallerXml.Tools.Melt.Run(string[] args) Line 113	C#
	melt.exe!Microsoft.Tools.WindowsInstallerXml.Tools.Melt.Main(string[] args) Line 62	C#
	[External Code]	

This condition is evaluated to true for this path System64Folder.AF4EABEE_4589_3789_BA0A_C83A71662E1D and consequently the CustomAction and InstallExecuteSequence is added to set the whole directory name to the [System64Folder]:

      if (Melter.StartsWithStandardDirectoryId(directory.Id, out standardDirectoryId) && !isTargetDir)
               this.AddSetPropertyCustomAction(directory.Id, String.Format(CultureInfo.InvariantCulture, "[{0}]", standardDirectoryId));
       /// <summary>
       /// Adds a SetProperty CA for a Directory.
       /// </summary>
       /// <param name="propertyId">The Id of the Property to set.</param>
       /// <param name="value">The value to set the Property to.</param>
       private void AddSetPropertyCustomAction(string propertyId, string value)
           // Add the action
           Wix.CustomAction customAction = new Wix.CustomAction();
           customAction.Id = propertyId;
           customAction.Property = propertyId;
           customAction.Value = value;
           // Schedule the action
           Wix.InstallExecuteSequence installExecuteSequence = new Wix.InstallExecuteSequence();
           Wix.Custom custom = new Wix.Custom();
           custom.Action = customAction.Id;
           custom.Before = "CostInitialize";

where propertyId = "System64Folder.AF4EABEE_4589_3789_BA0A_C83A71662E1D" and value = "[System64Folder]".

As the effect, these lines for CustomAction and InstallExecuteSequence are added to the reverse engineered WiX source files

       <CustomAction Id="System64Folder.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Property="System64Folder.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Value="[System64Folder]" />
       <CustomAction Id="System64Folder_amd64_VC.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Property="System64Folder_amd64_VC.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Value="[System64Folder]" />


           <Custom Action="System64Folder.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Before="CostInitialize" />
           <Custom Action="System64Folder_amd64_VC.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Before="CostInitialize" />

Talk is cheap, show me the specification

Here we go:

When a predefined directory is included in a merge module, the merge tool automatically adds a Custom Action Type 51 to the target database. The merge module author must ensure that a CustomAction table is also included. The CustomAction table may be empty, but this table is required to exist in the target database and ensures that the modified predefined directories are written to the correct locations. For example, when a system directory is included in a merge module, the merge module author must ensure that a Custom Action table exists.

Note that the matching algorithm for the generation of these type 51 custom actions only checks that the directory name begins with one of the predefined SystemFolder properties. It does not verify that the directory name exactly equals the directory property. Any directory beginning with one of these standard folder names gets a type 51 custom action, even if the rest of the name is not a GUID. Authors need to take care that this does not generate false positive matches, and unintended custom action generation, on derivative primary keys that begin with one of the SystemFolder properties.

If it is a bug in current code, why not to file a bug report then?


If the problem undeerstood, isolated, reproduced and working logic in WiX toolset was tracked down, why not to fix it in LO installer

What the LibreOffice installer would do if the problem would be fixed?


MSVC 2017 Debugger activation on unit test failures

It was fixed on the most recent master (thanks, mst_). All is needed now to say is:

 make CppunitTest_dbaccess_hsqldb_test CPPUNITTRACE=TRUE

after this Visual Studio is started and "Start" can be clicked to actually run the test.

Issues Fixed in MSVC 2015

MSVC 2015 Debugging Issues (FIXED)

Precompiled header issue (FIXED)


option doesn't work. The error is that the memory is needed is not sufficient, with the hint to increase the factor with /ZmXXX option:[1]. Even though the option was set to the max. allowed value: /Zm2000 in this change: [2]. This is still failing.

This looks like a compiler bug:

In context of this gerrit patch:

The value was increased from /Zm500 to /Zm2000. It was pointed out on MS's knowledge base, that at least in one case, it helped to remove this option entirely, to get rid of this error.

  • So replace it with this patch:

MS's knowledge base lists this bug reports:

with possible resolution:

  • Use "/Xm" instead of "/Zm" or switch to the 64-bit hosted compiler.
  • I have switched to the 64-bit compiler with <UseNativeEnvironment>true</UseNativeEnvironment> and now the errors are gone. Thank you very much!

.Net is broken (FIXED)

.Net part in unoil is failing to emit:

> error: .NET exception occurred: System.ArgumentException: Der Typ muss ein von der Laufzeit angegebener Typ sein.
Parametername: types
   bei System.DefaultBinder.SelectMethod(BindingFlags bindingAttr, MethodBase[] match, Type[] types, ParameterModifier[] modifiers)
   bei System.RuntimeType.GetConstructorImpl(BindingFlags bindingAttr, Binder binder, CallingConventions callConvention, Type[] types, ParameterModifier[] modifiers)
   bei System.Type.GetConstructor(BindingFlags bindingAttr, Binder binder, Type[] types, ParameterModifier[] modifiers)
   bei System.Type.GetConstructor(Type[] types)
   bei climaker.TypeEmitter.complete_struct_type(struct_entry entry)
   bei climaker.TypeEmitter.~TypeEmitter()
   bei climaker.TypeEmitter.Dispose(Boolean A_0)
   bei climaker.TypeEmitter.Dispose()
   bei ?A0x48efeb13.sal_main()
> dying abnormally...C:/Users/david/projects/libo/unoil/ recipe for target 'C:/Users/david/projects/libo/instdir/program/cli_oootypes.dll' failed
make[1]: *** [C:/Users/david/projects/libo/instdir/program/cli_oootypes.dll] Error 1


Root cause:

    public override MethodBase SelectMethod(BindingFlags bindingAttr,MethodBase[] match,Type[] types,ParameterModifier[] modifiers)
            int i;
            int j;
            Type[] realTypes = new Type[types.Length];
            for (i=0;i<types.Length;i++) {
                realTypes[i] = types[i].UnderlyingSystemType;
                if (!(realTypes[i] is RuntimeType))
                    throw new ArgumentException(Environment.GetResourceString("Arg_MustBeType"),"types");

LibreOffice window doesn't appear (FIXED)

Fixed with:

Soffice process is starting, but window doesn't appear:

Stack thread:

Info log:

To debug, add

  volatile int i = 1; while (i) {};

to the

int Desktop::Main()

method and change i to 0 once the debugger is attached.

Non supported modules (FIXED)

Module Problem Notes Action Status
graphite compile error Bug upstream: Fixed in
jpeg-turbo hard coded 86 platform Fixed Fixed in
libgltf hard coded 86 platform Fixed Fixed in
odk WError Fixed Fixed in
firebird link error Fixed upstream in 3.0 Fixed in

EH in uno bridge is broken (FIXED)

Uno bridge was fixed as of:

cd testtools && make

Installer is broken (FIXED)

Windows Installer tools

  • msiinfo
  • msidb
  • [...]

cannot be found on x64 bit build[3].

Why? Because Windows SDK bin path is set to:

C:\Program Files (x86)\Windows Kits\8.1\bin\x64

but the msi tools are only available in x86 directory:

C:\Program Files (x86)\Windows Kits\8.1\bin\x86

Fixed in

just works. Great job, Mark!


Tinderbox(s) that are building and uploading daily build artifact: E.g.: Win-x86_64@62-TDF, Win-x86_64@42.


MS Visual Studio C++ 2013 runtimes

The Tinderbox TB62 MSI packaging contains the Visual Studio 2013 C++ 64-bit redistributable runtime, msvcr120.dll but it can not install it with /A administrative install of the MSI package. If installing in parallel you will need to install the 64-bit msvcr120.dll runtime in advance of a /A install. Downloads (ARM, x86, x64) can be found here:

MS Visual Studio C++ 2015 runtimes

The Tinderbox TB42 MSI packaging contains the Visual Studio 2015 C++ 64-bit redistributable runtime, msvcr140.dll but it can not install it with /A administrative install of the MSI package. If installing in parallel you will need to install the 64-bit msvcr140.dll runtime in advance of a /A install. Downloads (x86, x64) can be found here:

The updated files would not be here?

Connectivity: discontinue ancient seamonkey based drivers and enable mork driver

In Windows 32 bit ancient seamonkey library is linked to provide Thunderbird, Outlook and Outlook-Express address book integration. Because this is a no go to compile seamonkey code in 64 bit mode, our own mork driver is activated on 64 bit platform. Still pending for review:

Connectivity: ADO driver is not available on x64

As it pointed out there are some porblems with ADO 64bit driver. That why ADO unit test is not working on64b bit platform and i deactivated for now. It needs to be investigated if it can be replaced with 64bit compatible driver or removed.

Unit test disabled with:

Long-term solution: migrate to Microsoft Access Database Engine 2010; see also tdf#56904. Probably just requires replacing "Provider=Microsoft.Jet.OLEDB.4.0" by "Provider=Microsoft.ACE.OLEDB.12.0"


As this is a new ABI, we should have gotten rid of /Zc:wchar_t-. We forgot to do that for LibreOffice 5.0, though. But on a quick look at least, it looks like none of the mangled C++ symbols in the stable URE interface actually depend on wchar_t, so it should be possible to still fix that without breaking backwards compatibility. (And thus should also be possible to fix for the 32-bit MSVC URE ABI.) TODO

Broken C++-UNO Bridge

With core commit 28787edbd8a6bc1e3a6486d42f316cc54a7ff0e3, calls from UNO to C++ are restricted to MAXPARAMS = 20 parameters, failing with a “Too many parameters!” RuntimeException otherwise. But ooo.vba.excel.XApplication.Intersect (in oovbaapi/ooo/vba/excel/XApplication.idl) has 30 parameters, causing CppunitTest_sc_macros_test to fail.

Partially addressed with core commit 8bcc538953ceec4ef266f16cf72329bc6080d08c. TODO: true fix.

Warning free build

--enable-werror currently doesn't work on MSVC 14.0. With core commit 133610669b8707a278d9b3b0af025779044fd8c5, further warnings were silenced by adding this option -Wv:18. (See the paragraph “The /Wv flag” of Visual Studio 2015 RTM for a description of that flag.)

Partially addressed with

TODO: revert this core commit 133610669b8707a278d9b3b0af025779044fd8c5 and fix all warnings.