so it can code following the CPPUNIT_ASSERT doesn't need
to check what condition might have failed in the assert
Change-Id: Ife7e5e54b17a8316425222d2a0efd694c9467089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167480
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
...to avoid
> workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:115:8: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
> sprintf(buffer, "%.*g", precision, x);
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
> __deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
> #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
> ^
on macOS after the upcoming <https://gerrit.libreoffice.org/c/core/+/147257>
"Don't mis-apply GCC < 4.6 workaround for Clang"
Change-Id: I213de1d112cb56fba220006842e611c56ccc7331
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147333
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Often a developer debugging a failing CppUnit test wants a core dump with the
place where an uncaught exception is thrown. So if the newly introduced
CPPUNIT_PROPAGATE_EXCEPTIONS environment variable is set (to any value), disable
all the protectors that would otherwise catch such exceptions (and just report
some limited information about them).
Change-Id: I3052f71c0787583c496279a6f5b35a0299c357b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143882
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
macOS Ventura replaced the patch utility by Apple's version:
patch 2.0-12u11-Apple (as of macOS 13.0.1)
It is picker/less robust when it comes to locating matches, and absolutely
refuses to apply when the hunks are out of order. Only one patch needed
rework in the current codebase (master an 7-4 branch), and being more correct
about the locations in the files to be patched is not a bad thing either, so
accept Apple's version of patch (with a warning for now)
Change-Id: I707d00958b814307b13caf9923f1de7f3919442c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143461
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Building LO with WASM native EH and Emscripten 3.1.6+, the link
fails with a missing "emscripten_longjmp" symbol. Actually the
old build was simply wrong, because the emscripten_longjmp
function is just used for the Emscripten SjLj and not the native
WASM SjLj implementation. Linking just worked, because the used
libcompiler_rt-wasm-sjlj-mt.a lib was incorrectly providing that
symbol, which 3.1.6 removed.
But since running the NEH build still fails early in the same way
then before in FF nightly 100 and Chrome (= failure in the LO job
scheduler calling Task::UpdateMinPeriod for the "desktop::Desktop
m_firstRunTimer" timer, resulting in a WASM VM "RuntimeError:
indirect call signature mismatch"), there is still no way to know,
if nothing else it missing. The Emscripten / JS EH build still
works without any code changes. And it's not the first call on
a job object that fails...
And unfortunatly, because Qt itself also uses libpng, it also uses
SjLj for error handling, like LO in the image import, so the Qt
build must also be patched to build with "-s SUPPORT_LONGJMP=wasm".
Simply enough to do (see README.wasm.md). LO's configure now
detects that symbol and will bail out on incompatible Qt and LO
build setup.
See https://github.com/emscripten-core/emscripten/issues/16572
Change-Id: I3a1877f3aeb77873906176b9d3cd1ea92973f1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132139
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(this was meant as a prerequisite for enabling its -D_LIBCPP_DEBUG=1 counterpart
when building against libc++ on macOS, but which got stalled for now after
running into the issue described at
<https://lists.llvm.org/pipermail/libcxx-dev/2021-October/001222.html>
"[libcxx-dev] Building a program with -D_LIBCPP_DEBUG=1 against a libc++ that is
not itself built with that define")
Change-Id: If466dce595a9311b2afbae41d5ddcaecc6f3c57b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124678
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This allows to define the mapping once, and avoid modification in
multiple places each time a new VS version support is added
Change-Id: I93de4c9d78c3f67a0a2e157007e9d13b6f557937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This patch changes the configure.ac, so that LibreOffice compiles
with the latest VS 2022 preview.
The option --with-visual-studio=2022 should be added to the
autogen.input, in order to use VS 2022 preview.
Change-Id: Ia1d9bbeabbbd44ffe82af3624151b69d36c0a45c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122133
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Adds three Windows gb_* variables:
- gb_MSBUILD_CONFIG_AND_PLATFORM can be passed as msbuild flags
- gb_MSBUILD_PLATFORM maps debug / release settings
- gb_MSBUILD_CONFIG maps the CPUTYPE to the default msbuild names
and converts the users in external projects.
Change-Id: Ie9b817721180d78d104db11c44241e4b3e46bba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102701
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
What prompted me to make this change is that when I tried an --enable-lto build,
CppunitTest_xmlsecurity_signing failed in a non-obvious way, and I noticed that
it ran the individual tests in a different order than a --disable-lto build.
With this change, CppunitTest_xmlsecurity_signing also started to fail in the
--disable-lto build, which has meanwhile been fixed with
800eebfa82 "Database document apparently needs to
be closed before it is disposed". No other tests started to fail in my
Linux --disable-lto-build with this change, and my Linux --enable-lto build
(using recent Fedora 32 GCC 10.2 and the default linker) also succeeds `make
check` after 800eebfa82, both with and without
this cppunit change.
(<https://bugs.documentfoundation.org/show_bug.cgi?id=126442> "LTO build
segfaults in sw_apitests" and <https://src.fedoraproject.org/rpms/libreoffice/c/
5d644f1606b76ffa4a102433849a824d7293a404> "%check fails with lto enabled"
indicate that older branches also fail CppunitTest_sw_apitests with
--enable-lto, but I could not reproduce that on current master.)
What happens in cppunit is that every CPPUNIT_TEST_SUITE_REGISTRATION (or other
macro like CPPUNIT_TEST_FIXTURE internally calling
CPPUNIT_TEST_SUITE_REGISTRATION) creates a global static variable whose ctor
inserts the address of a sub-object of that global static variable into the
TestFactoryRegistry::m_factories set. Even if the order of invocation of those
ctors from one .cxx is deterministic, the relative order or the addresses of
those sub-objects inserted into the TestFactoryRegistry::m_factories set need
not be (though they probably typically are). Another source of nondeterminism
is that the order of ctors from different .cxx is not specified (which might
have caused the CppunitTest_xmlsecurity_signing failures, given that test
includes suites from two different .cxx).
So to make test execution more reproducible, make the order in which the tests
are run deterministic, sorting them by name. (When
TestFactoryRegistry::addTestToSuite the adds the sorted tests to
TestSuite::addTest, they are inserted into a TestSuite::m_tests vector, from
which point on things appear to already happen in a deterministic order.)
Change-Id: I40741f397a96772974fd41bacdb3dd763c885417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100384
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(where 16.4 is currently the latest version of Visual Studio 2019 available at
<https://visualstudio.microsoft.com/downloads/>), see
<https://lists.freedesktop.org/archives/libreoffice/2020-February/084575.html>
"ESC meeting minutes: 2020-02-27": "Update baseline to VS2019 on master before
7.0 [...] check what’s the current patch level, require that? [...] no
objections"
The code from 4ea0059bca "VS detection: Fallback
to old registry check if vswhere failed" has been removed in accordance with its
comment "The below hack does not work for VS 2019 anyway, so should be removed
when upgrading baseline.
(Changing the comment "go to Start menu, open 'Visual Studio 2017', [...]"
regarding the installation of GNU Make from source is somewhat arbitrary, but
lets stick to the tradition of bumping that version number along with any build
baseline bump.)
Change-Id: Ic4fe8a3d347aa1748377f2d3205e302bff189b79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89699
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This includes a revert of commit 9808486a89 "Avoid
-Werror,-Wimplicit-fallthrough with clang-cl", and also undoes older MSVC
workarounds (that would start to cause "warning C4702: unreachable code" now).
Change-Id: If72bf336e12e0a2db589857e8875003dae861977
Reviewed-on: https://gerrit.libreoffice.org/67248
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
I am writing a separate unit test app that will include selected
existing unit tests that make sense and are important to run on iOS.
Change-Id: I4722f1ed872ba21e181eeba5ed3b58e82d8fed72
Reviewed-on: https://gerrit.libreoffice.org/61049
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Note: this maps to /Z7 apparently:
<DebugInformationFormat>OldStyle</DebugInformationFormat>
https://msdn.microsoft.com/en-us/library/bb629394.aspx
lists various options but passing /p:DebugSymbols=true /p:DebugType=full
/p:PdbFile=... to msbuild.exe by itself doesn't do anything while
patching the project file works.
Change-Id: I888b5f6af7be519e2d35b749873ae7d35bb0bf9d
Reviewed-on: https://gerrit.libreoffice.org/56605
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it
arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later
Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79
Reviewed-on: https://gerrit.libreoffice.org/45163
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...introduced with b862cbdd34 "Support MSVC 15.0",
but $(filter ...,) always expands to the empty string, and this is probably what
was intended.
Change-Id: I5865ea13ba3c3d52402bcba48f4f770f6c2b8862
Reviewed-on: https://gerrit.libreoffice.org/34482
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Stephan Bergmann