Development/msvc-x86 64

LibreOffice x64 is UP AND RUNNING:


 * vcldemo: http://imgur.com/FeGtSX1
 * LibreOffice: http://imgur.com/1Z27hMq

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

Releases
TDF releases available since LibreOffice 5.0 (listed as &ldquo;Windows x86_64 (Vista or newer required)&rdquo;).

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


 * https://dev-builds.libreoffice.org/daily/master/Win-x86_64@62-TDF/current/
 * https://dev-builds.libreoffice.org/daily/master/Win-x86@42/ (VS2015)

libgpg-error
Build works, pending change: https://gerrit.libreoffice.org/34530

libassuan
Build works, pending change: https://gerrit.libreoffice.org/42745

gpgmepp
Build works, pending change: https://gerrit.libreoffice.org/42838 Linking is failing to resolve symbols:


 * http://paste.openstack.org/show/622410
 * http://paste.openstack.org/show/622411

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/libassuan.la. *** 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/libgpg-error.la. *** 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: http://ostrovsky.org/libo/libgpgme-11.dll

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

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

https://connect.microsoft.com/VisualStudio/feedback/details/1639267/c-runtime-and-mfc-merge-modules-for-x64-are-broken-install-to-syswow64-instead-of-system32 - here MS claims that since VS 2015 U1, the merge modules for 64-bit runtime are fixed https://connect.microsoft.com/VisualStudio/Feedback/Details/1746644 here is a hack is provided with Orca how to "fix" merge module https://connect.microsoft.com/VisualStudio/Feedback/Details/1743566

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: https://www.microsoft.com/en-us/download/details.aspx?id=48145.
 * 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

with

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: http://paste.openstack.org/show/594623 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: WiX toolset contains  utilitiy to decompile the MSI:

Dark

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:

http://paste.openstack.org/show/594630/

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

Melt

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

Feeding  with   we get this WiX source description:

http://paste.openstack.org/show/594631/

So, clearly we are losing these two lines:

 

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:

http://lists.wixtoolset.org/htdig.cgi/wix-users-wixtoolset.org/2015-September/000227.html

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

https://connect.microsoft.com/VisualStudio/feedback/details/1746644

And was later reported as has been fixed.

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


 * Set up WiX3
 * Build it
 * Debug session  decompiler with this parameters:

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

AdminToolsFolder AppDataFolder CommonAppDataFolder CommonFiles64Folder CommonFilesFolder DesktopFolder FavoritesFolder FontsFolder LocalAppDataFolder MyPicturesFolder NetHoodFolder PersonalFolder PrintHoodFolder ProgramFiles64Folder ProgramFilesFolder ProgramMenuFolder RecentFolder SendToFolder StartMenuFolder StartupFolder System16Folder System64Folder SystemFolder TARGETDIR TempFolder TemplateFolder WindowsFolder WindowsVolume

With this code path:

This condition is evaluated to  for this path   and consequently the   and   is added to set the whole directory name to the  :

where  and.

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

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 the problem undeerstood, isolated, reproduced and working logic in WiX toolset was tracked down, why not to fix it in LO installer
https://gerrit.libreoffice.org/33366

What the LibreOffice installer would do if the problem would be fixed?
http://paste.openstack.org/show/595977/

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.

{| class="wikitable mw-collapsible mw-collapsed" ! Issues Fixed in MSVC 2015

MSVC 2015 Debugging Issues (FIXED)

 * Problems with debugging. Cannot set any breakpoints from the source file, see http://nabble.documentfoundation.org/Debugging-specifics-wrt-visual-studio-td4185447.html. Should be fixed with.

Precompiled header issue (FIXED)
--enable-pch

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:. Even though the option was set to the max. allowed value: /Zm2000 in this change:. This is still failing.

This looks like a compiler bug:


 * http://paste.openstack.org/show/155658
 * http://paste.openstack.org/show/155659

In context of this gerrit patch:


 * https://gerrit.libreoffice.org/#/c/13209/6/solenv/gbuild/platform/com_MSC_defs.mk,cm

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:

https://gerrit.libreoffice.org/#/c/13779

MS's knowledge base lists this bug reports:


 * https://connect.microsoft.com/VisualStudio/feedback/details/800059/isnativeenvironment-true-no-longer-works-on-visual-studio-2013-rc
 * https://connect.microsoft.com/VisualStudio/feedback/details/808945/torino-error-c3859-c1076

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 true 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/CliUnoApi_oootypes.mk:13: 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

Fixed:


 * https://gerrit.libreoffice.org/13851

Root cause:


 * http://referencesource.microsoft.com/#mscorlib/system/defaultbinder.cs,6feb597d199c87b2

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:


 * https://gerrit.libreoffice.org/#/c/13807

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

Stack thread:

http://paste.openstack.org/show/154768

Info log:

http://paste.openstack.org/show/155636/

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.

EH in uno bridge is broken (FIXED)
Uno bridge was fixed as of:

https://gerrit.libreoffice.org/#/c/13653

cd testtools && make

Installer is broken (FIXED)
Windows Installer tools


 * msiinfo
 * msidb
 * [...]

cannot be found on x64 bit build.

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


 * https://gerrit.libreoffice.org/#/c/13878

just works. Great job, Mark!
 * }

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

master

https://dev-builds.libreoffice.org/daily/master/Win-x86_64@62-TDF/current/

5.0

https://dev-builds.libreoffice.org/daily/libreoffice-5-0/Win-x86_64@62-TDF/current/

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: http://www.microsoft.com/en-us/download/details.aspx?id=40784

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: http://www.microsoft.com/en-us/download/details.aspx?id=48145

The updated files would not be here? https://support.microsoft.com/en-us/kb/2977003

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:

https://gerrit.libreoffice.org/17349

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.


 * https://social.msdn.microsoft.com/Forums/en-US/d5b29496-d6a1-4ecf-b1a4-5550d80b84b6/microsoftjetoledb40-32bit-and-64bit?forum=adodotnetdataproviders

Unit test disabled with:


 * https://gerrit.libreoffice.org/13367

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

URE ABI
As this is a new ABI, we should have gotten rid of. 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, 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, calls from UNO to C++ are restricted to  parameters, failing with a     otherwise. But  (in  ) has 30 parameters, causing   to fail.

Partially addressed with. TODO: true fix.

Warning free build
currently doesn't work on MSVC 14.0. With, further warnings were silenced by adding this option. (See the paragraph &ldquo;The /Wv flag&rdquo; of Visual Studio 2015 RTM for a description of that flag.)

Partially addressed with



TODO: revert this and fix all warnings.