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

    From The Document Foundation Wiki

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


    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.

    Releases

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

    Testing

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

    Ongoing efforts to build gpgme on Windows

    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:

    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

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

    Status

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

    Ongoing efforts to support MSVC 14.0 (aka VS 2015)

    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: C:\Windows\System32 WiX toolset contains dark.exe 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 melt.exe 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 melt.exe with Microsoft_vc140_CRT_X64.msm we get this WiX source description:

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

    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:

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

       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: 

    	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;
           this.fragment.AddChild(customAction);

               // Schedule the action
           Wix.InstallExecuteSequence installExecuteSequence = new Wix.InstallExecuteSequence();
           Wix.Custom custom = new Wix.Custom();
           custom.Action = customAction.Id;
           custom.Before = "CostInitialize";
           installExecuteSequence.AddChild(custom);
           this.fragment.AddChild(installExecuteSequence);
       }

    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]" />

    [...] 

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

    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?

    tdf#105311

    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/

    References

    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)

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

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

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

    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:

    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.

    Non supported modules (FIXED)

    Module Problem Notes Action Status
    graphite compile error http://paste.openstack.org/show/145976/ Bug upstream: http://projects.palaso.org/issues/1310 Fixed in https://gerrit.libreoffice.org/14316
    jpeg-turbo hard coded 86 platform Fixed Fixed in https://gerrit.libreoffice.org/14315
    libgltf hard coded 86 platform http://paste.openstack.org/show/168553 Fixed Fixed in https://gerrit.libreoffice.org/14542
    odk WError Fixed Fixed in https://gerrit.libreoffice.org/14541
    firebird link error Fixed upstream in 3.0 Fixed in https://gerrit.libreoffice.org/#/c/27642/

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

    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.

    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"

    URE ABI

    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 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 8bcc538953ceec4ef266f16cf72329bc6080d08c. TODO: true fix.

    Warning free build

    --enable-werror currently doesn't work on MSVC 14.0. With 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 133610669b8707a278d9b3b0af025779044fd8c5 and fix all warnings.


    References

    1. ↑ http://msdn.microsoft.com/en-us/library/vstudio/bdscwf1c%28v=vs.120%29.aspx
    2. ↑ https://gerrit.libreoffice.org/13209
    3. ↑ http://paste.openstack.org/show/156242/
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Development/msvc-x86_64&oldid=687958"