Update 15.3 renamed redist directory from 150 to 141 and introduced
intermediate build number directories, that are different from the
compiler build number directories.
While the compiler is located under:
[...]/MSVC/14.11.25503/bin/HostX64/x64/cl.exe
the merge modules are located now under:
VC/redist/MSVC/14.11.25325/MergeModules
Change the hard coded detection approach, to the dynamic one: list
all directories in suspected locations and check for existnace of
the artifacts we are looking for.
Change-Id: Ie040f290d1748ab4ec5c715b6636cc3733329e1c
Reviewed-on: https://gerrit.libreoffice.org/41922
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
/debug:fastlink improve build performance and reduce resources
consumption. When this linker oprion is used the linker-produced
program database (PDB) files doesn’t have any private symbol
information. Debug information is distributed among input object
and library files, and the linker PDB just serves as an indexing
database. Obviously, this provides a huge performance benefit for
the daily developer builds.
fastlink PDB files cannot be shared with another developer on the
team or uploaded directly to symbol server. There is spcial tooling
which is able to create a full PDB from the /debug:fastlink PDB
on demand: mspdbcmf: [1]. The integration of mspdbcmf is beyond
the scope of this change.
[1] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-build-cycle-in-vs-15-with-debugfastlink/
Change-Id: I14e29cf116407b420598f692c8d6d851e686268b
Reviewed-on: https://gerrit.libreoffice.org/34330
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
New compiler changes quite some stuff:
* Compiler detection done based on different registry key
* .NET SDK detection done based on different registry key
* Msbuild installation directory changed
* Merge modules installation directory changed
* SDK number in registry doesn't match the directory name:
(registry key: 10.0.14393, directory name: 10.0.14393.0)
* Compiler, include and library location directories changed
* Architecture specific directory changed: x64 instead of amd64
* Compiler own include directory must be added with -I option
* To force usage of SDK 10 (8.1 is selected per default) new
switch WindowsTargetPlatformVersion is passed to msbuild, to
avoid patching VC project files with this line:
<WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion>
Known issues:
* Firebird is broken: http://paste.openstack.org/show/594333
Change-Id: I148d7932aff43bbbd07bd493504df974726234c2
Reviewed-on: https://gerrit.libreoffice.org/31279
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Starting from MSVC 14.0, the directory table layout of VC++ Runtime merge
module changed. As consequence, all MSI produced with newer compilers,
including MSVC 15.0 (aka VS 2017) are broken in term that the VC++
Runtime DLLs are installed in the wrong directory, e.g.: C:\System64.
According to the specification for merging merge module (msm), see:
"Authoring Merge Module Directory Tables": [1], custom action 51 (set
property) must be emitted for every directory name in the merge module
directory table if the directory name is starting with the standard
directory name.
Quoting it here:
"
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."
Rectify the problem by analyzing the directory table from the merge
module, checking whether the directory name starts with the standard
prefix name and if it is the case, emitting custom action 51 to set this
variable to the standard directory name.
Implementation details:
We use the existing facility for emitting the custom action table events
including referencing them in the corresponding sequence tables. Given
that the specification above doesn't mention what sequence table should
be referencing this emitted custom action, we reversed engineer this
information from WiX toolkit. Merging the VC++ CRT module with WiX
toolkit and investigating the resulting MSI with Orca MSI reader, reveals
that these sequence tables were referencing from these sequence tables:
* AdminExecuteSequence
* AdminUISequence
* AdvtExecuteSequence
* InstallExecuteSequence
* InstallUISequence
Replicate this behaviour here as well. Note, though, that custom actions
are generally not referenced in AdminUISequence and AdvtExecuteSequence
tables in LibreOffice MSI building tool chain.
Rendering of the custom action is achieved by programmatic emulation of
custom action in SCP module. Consider this similar SCP module based
action:
Name = "MigrateInstallPath";
Typ = "321";
Source = "shlxtmsi.dll";
Target = "MigrateInstallPath";
Inbinarytable = 1;
Assignment1 = ("InstallExecuteSequence", "", "CostInitialize");
Assignment2 = ("InstallUISequence", "", "CostInitialize");
We instantiate the following data structure to emit custom action
System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1:
Name = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
Typ = "51"
Source = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
Target = "[System64Folder]"
Styles = "NO_FILES"
Assignment1 = ("AdminExecuteSequence", "", "CostInitialize")
Assignment2 = ("InstallExecuteSequence", "", "CostInitialize")
Assignment3 = ("InstallUISequence", "", "CostInitialize")
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa367787%28v=vs.85%29.aspx
Change-Id: I2fbd37ff63298d99b2ba1b6afe6e875f56d8e378
Reviewed-on: https://gerrit.libreoffice.org/33366
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
was not implemented as a built-in type, but was declared in wchar.h as
a typedef for unsigned short. Now, years later after the end of life
this outdated toolchain, there is no reason not to use native type.
The only issue could be the ABI compatibility. 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.
We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
5.2, though.
Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
Reviewed-on: https://gerrit.libreoffice.org/22589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Without explicitly specifying toolset v140, the build was
failing when only MSVC 14.0 was installed:
The builds tools for v120 (Platform Toolset = 'v120')
cannot be found
Change-Id: I6fb386d56e38cbf922de5069e70a3d3def147c0b
Reviewed-on: https://gerrit.libreoffice.org/23162
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: Jenkins <ci@libreoffice.org>
Without explicitly specifying toolset v140, the build was
failing when only MSVC 14.0 was installed:
The builds tools for v120 (Platform Toolset = 'v120')
cannot be found
Change-Id: I5849821f291b705ad75db8b4c9404af8458902ba
Reviewed-on: https://gerrit.libreoffice.org/23160
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
outdir doesn't seem to be created. Use current directory for
pdb files as the obj files are already stored in the current
directory.
Change-Id: I41dd65714d314cd374cc5de073d48f1a58b18c56
Reviewed-on: https://gerrit.libreoffice.org/22888
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Iterator category tags carry information that can be used
to select the most efficient algorithms for the specific
requirement set that is implied by the category. OsiCuts
defines bidirectional category tag, but doesn't implement
operator--(). This is illegal: [1].
* [1] http://paste.openstack.org/show/489235
Change-Id: I68a6d297d5c33848c4b8a324e081c5118fd936a4
Reviewed-on: https://gerrit.libreoffice.org/22882
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
This fixed this warning:
cygpath: cannot create short name of \
C:\PROGRA~2\WI3CF2~1\NETFXSDK\4.6\bin
Change-Id: I2d4e3d2c5e4c3348552355f91a340438eb0f9e8a
Reviewed-on: https://gerrit.libreoffice.org/22850
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
Set up the toolchain to create sources and javadocs artifacts in
addition to JARs created during the build. Use Buck build tool for
that: [1]. This is a fork of Google's build tool Blaze, created by
Xooglers at Facebook. This build tool (like Blaze itself) uses
Python to write build files.
Add needed tools and build files to install LibreOffice API artifacts
to local Maven repository or deploy them to Maven Central.
To build all needed artifacts LibreOffice must be built regularly
with GNU make first. To build the rest of the API (sources and
javadocs):
$> buck build api
To replace version number with upcoming release version:
$> solenv/bin/version.py 5.1.0
To install the API to local Maven repository:
$> buck build api_install
To deploy the API to Maven Central:
$> buck build api_deploy
Detailed documentation is added to document the prerequisites and
the workflow to upload LibreOffice API to Maven Central.
* [1] https://buckbuild.com
Change-Id: Ibdd552a01110836703bc069abe829b9921491cac
Reviewed-on: https://gerrit.libreoffice.org/20343
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Mozilla bootstrap driver is used in xmlsecurity to discover default
profile and induce the path to the public keys file location from
certification authorities. The same profile discovery code is used
in mork driver. Remove duplicated code and re-use the service from
mozilla bootstrap driver in mork driver.
Change-Id: I6bc271ccf75e89eb81767186ddd9078c1f64b73d
Reviewed-on: https://gerrit.libreoffice.org/20111
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
Since df62a2c81b gb_DEBUG_CFLAGS
was passed to bridge_noopt_objects target for MSVC to track
down EH breakage on 64 bit architecture. It was erroneously
done unconditionally. Fix it to only pass when one of:
--enable-dbgutil
--enable-debug
--enable-symbols
is present.
Change-Id: I2728c30156541be418c88a0ea284c0c6a16abba5
Reviewed-on: https://gerrit.libreoffice.org/19744
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Starting with MSVC 14.0 (aka VS 2015) C Runtime (CRT) was divided in
two logical parts: The VCRuntime, which contained the compiler support
functionality required for things like process startup and exception
handling, and a "stable" part that contained all of the purely library
parts of the CRT.
Previously, all of the CRT headers, sources, and libraries were
distributed as part of the Visual C++ SDK, installed in the VC
subdirectory of Visual Studio installation (generally C:\Program
Files (x86)\Microsoft Visual Studio 14.0\VC). The files for the
VCRuntime are still part of the Visual C++ SDK. The headers, sources,
and libraries are now distributed as part of a separate Universal CRT
SDK. This SDK is included with Visual Studio; it is installed to
C:\Program Files (x86)\Windows Kits\10. The debug ucrtbased.dll is
also included as part of this SDK and is installed to the system
directory.
In I0ef8cda7b initial support was added to suport VS 2015. In this
change support for universal CRT, .NET 4.6 and SDK 10 is added. UCRT
dirs are added to CFLAG, CXXFLAG and ILIB. SDK 10 include path is
added to SOLARINC. .NET Framework 4.6 was splitted from SDK 10 and
needs to be discovered separately.
Change-Id: I2c484b6b1debab0d71523385021abb8fc8e6027f
Reviewed-on: https://gerrit.libreoffice.org/16642
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Seamonkey based address book driver is based on pre-compiled libraries
and is only used on Windows 32 bit. Remove it in favor of mork driver.
Given that Seamonkey based mozab driver also provides Outlook and
Outlook Express address book integration, that Windows-32-bit--only
feature is lost for now. If necessary, support for that feature could
be rewritten from scratch, in a way that would also work for Windows 64
bit.
Change-Id: Ie1c125e692598bda999767c328c9e2262a2b82af
Reviewed-on: https://gerrit.libreoffice.org/19560
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
3.5 release is needed for MSVC 14.0 (aka VS 2015) support. Python 3.5
removed build toolchain support for MSVC 2013. Because we still need
to support it, we duplicate the Python directory in externals and
copy old patches and dispatch to this directory for MSVC 2013. Once
the support for MSVC 2013 is dropped on master, this directory can be
removed again.
Change-Id: Idf7bc351239582f583ecbdb53c923cbdcf968089
Reviewed-on: https://gerrit.libreoffice.org/17352
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
VC runtime was substantially refactored on MSVC 14.0. Among other,
_tiddata structure defined in crt/src/mtdll.h was replaced with
__vcrt_getptd defined in crt/src/vcruntime/vcruntime_internal.h.
All members before
unsigned long _NLG_dwCode
were removed, so that the approach to access the member
void * _tpxcptinfoptrs; /* ptr to exception info pointers */
with __pxcptinfoptrs() and compute the offset to the _curexception
member of _tiddata doesn't work on MSVC 14.0.
As of MSVC 14.0 __vcrt_getptd symbol isn't exported but Microsoft
have introduced methods to access current exception, current exception
context and processing throw (the later can be accessed through C++17
std::unhandled_exceptions() that was made available in MSVC 14.0):
* __current_exception()
* __current_exception_context()
* __processing_throw() aka std::unhandled_exceptions()
Make use of __current_exception() which we can hope will be maintained
going forward.
Change-Id: Ibfffa5fba62d6928328ac976cb1b24937277363e
Reviewed-on: https://gerrit.libreoffice.org/18475
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
The member is inherited from a nonpublic virtual base class or
structure.
Declaring copy ctor and assignment operator as deleted in derived
class solved the problem.
Change-Id: Ic509f7e7311fd896656ecff80df3ece4503c3a65
Reviewed-on: https://gerrit.libreoffice.org/18328
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
MSVC 14.0 was failing to compile IMark class an friends with:
error C2280: 'SwModify &SwModify::operator =(const SwModify &)':
attempting to reference a deleted function: [1].
After defining copy ctor and assignment operator in SwModify and
derived classes as deleted the next failure was:
error C2512: 'sw::mark::IMark::IMark': no appropriate default
constructor available: [2].
Defining default ctor as default in IMark and derived classes
seems to make all compilers happy.
[1] http://paste.openstack.org/show/447854
[2] http://paste.openstack.org/show/447856
Change-Id: I2822e8ec4b98ca18d0a0128ed2ceeb38f347c5bf
Reviewed-on: https://gerrit.libreoffice.org/18362
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Make the workaround in snprintf.h conditional on older MSVC version.
Investigation reveals that the GetShortPathNameW is presumably used by
legacy Duden extension that was built by Sun in a setsolar environment.
The uwinapi.lib was never part of the SDK, so ordinary extensions cannot
link against it. The PRIVATE export of the symbol that is only possible
with DEF file therefore does not matter much. With VC2015 there is no
need for LO code to use uwinapi.dll at all and gb_UWINAPI can be unset
in this case.
Change-Id: I23a5636db9431b0fa4350b665a6a69613d625264
Reviewed-on: https://gerrit.libreoffice.org/16677
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
9a6cdce37e was trying to fix the problem
with exposing deprecated vars and functions in system's error_code.hpp
include file by patching bundled boost version. This approach would
only make sense, when upstream version is going to be fixed ASAP. Apply
another approach, and follow the same pattern as applied in external
libraries, by defining
-DBOOST_ERROR_CODE_HEADER_ONLY \
-DBOOST_SYSTEM_NO_DEPRECATED
instead of patching bundled boost version. This way, the code would
work with unpatched system boost 1.59 final as well.
Change-Id: I8684ca458ea4a5b7d7c3c3acfe7c14a6d19bc665
Reviewed-on: https://gerrit.libreoffice.org/18201
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
David Ostrovsky