This is basically ea68de2968 but
for LDFLAGS. A number of external libs cannot use this because
their libtool mishandles -fuse-ld.
Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
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>
...split from -fuse-ld with <https://github.com/llvm/llvm-project/commit/
1bc5c84710a8c73ef21295e63c19d10a8c71f2f5> "[Driver] Add --ld-path= and deprecate
-fuse-ld=/abs/path and -fuse-ld=rel/path", and now causing warnings (or even
errors with -Werror) like
'-fuse-ld=' taking a path is deprecated. Use '--ld-path=' instead
when --enable-ld is configured as a full path. (--enable-ld was vague whether
it supports full paths, but it appeared to work reasonably well at least with
old versions of Clang.)
Change-Id: I5a7dfd992b56aba78dd3646045fb9a827dc40321
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99569
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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 attempt tries to avoid affecting other .wk1 files as well.
The old fix was even applied to the wrong patch section, not done for
MacOSX or Windows. Geez..
Change-Id: Ia79383f33ff760cba9bfb44f166e27f3ef212c57
Reviewed-on: https://gerrit.libreoffice.org/83431
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
see commit message of
external/libwps/0001-Make-comparison-operator-member-functions-const.patch for
details
Change-Id: Ib8702f57f47aacc08628ceaccce23b487660b95c
Reviewed-on: https://gerrit.libreoffice.org/81249
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I think this is all external libs where it makes sense for them
to have their own PCH and be worth it. Maybe some smaller externals
can also use the common system PCH, but unfortunately many externals
use all kinds of defines that affect system headers, which is
a problem for the common system PCH.
Change-Id: I2c589ac55d93728daf3b158df110722e5f055d45
Reviewed-on: https://gerrit.libreoffice.org/80728
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Also return the proper kind and creator values set in
WKS4Parser::checkHeader() to callers of
WPSDocument::isFileFormatSupported()
Change-Id: I3adfde0e18669b80956a9b577080fe8388dd3b1f
Reviewed-on: https://gerrit.libreoffice.org/79981
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
...for ASan/UBSan builds using Clang older than current trunk twoards Clang 9,
as announced at
<https://lists.freedesktop.org/archives/libreoffice/2019-May/082654.html> "Re:
[Libreoffice-commits] core.git: The -fvisibility-ms-compat hack is no longer
needed for UBSan on Linux...". (And drop the no longer needed
solenv/sanitizers/asan-suppressions, which people might still reference from
their ASAN_OPTIONS.)
Change-Id: Iedc0c5955366d2cbe7dc847990e2b1576750e85b
Reviewed-on: https://gerrit.libreoffice.org/72493
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As in, really disable, so that they do not even show. This moreover
avoids tons of D9025 warnings from MSVC about overriding -W4 with -w.
Change-Id: Ia2e72fd72d883d91bdd89e467ee42f259e2ae033
Reviewed-on: https://gerrit.libreoffice.org/72899
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
These are larger C++ libs and without gdb-index gdb takes a moment
to load such libs.
Change-Id: I555a629199f761060199a528415f7d5fbe9d9533
Reviewed-on: https://gerrit.libreoffice.org/71822
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...with latest Clang trunk towards Clang 9. All the no-longer necessary hacks
are made conditional on new NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY, which is
still set for UBSan builds with older Clang on Linux (but which should
eventually be purged).
Various classes needed additional SAL_DLLPUBLIC_RTTI annotations, as building
with UBSan instrumentation can generate references to RTTI symbols from
additional places like outside a dynamic library that used to hide those symbols
by default (but used to not hide them for old UBSan builds thanks to the
-fvisibility-ms-compat hack).
The odr-violation suppressions in solenv/sanitizers/asan-suppressions (which is
not referenced from anywhere in the code base, but meant to be included in an
ASan/UBSan build's ASAN_OPTIONS env var) are also no longer needed when
NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY is false.
Change-Id: I24ec3e388b0cbab50dbe2bf008d9569bff7bf25a
Reviewed-on: https://gerrit.libreoffice.org/70829
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit cc2bc0bf3c. As discussed at
<https://gerrit.libreoffice.org/#/c/55783/> "Fix nan is not a member of std when
building android":
Stephan: "with exactly what architecture and toolchain did that failure happen;
is this commit still relevant after <https://gerrit.libreoffice.org/plugins/
gitiles/core/+/312eeeee42cb4a1e356943e17305555e41afc4ef%5E!/> 'Switch Android
armeabi-v7a to libc++/libc++abi/libunwind too'?"
Tomaž: "It was a consequence of that limited Bionic libstdc++ that was used in
ANdorid. libc++ should be a modern up-to-date replacements so I guess this
workaraunds are now obsolete and irrelevant."
(And a --with-distro=LibreOfficeAndroid build against NDK r16b indeed succeeded
for me with this revert.)
Conflicts:
external/libwps/UnpackedTarball_libwps.mk
Change-Id: I2dba64e5712b20fa07f6374ae01c226025c52d8b
Reviewed-on: https://gerrit.libreoffice.org/66390
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>
Otherwise, CppunitTest_sw_odfexport (which happens to load both libwps and
libnumbertext) on Linux --enable-dbgutil would cause a crash when
testSpellOutNumberingTypes calls into libnumbertext's use of std::regexp, which
instantiates a std::__detail::_NFA<...> with std::__debug::vector<...> members,
but happens to bind to libwps' (exported, inline) functions to destroy that
_NFA again, and libwps' view of std::__detail::_NFA<...> uses non-debug plain
std::vector<...> members.
(Copy/pastes the code to enable _GBLICXX_DEBUG as already used in various other
external/ExternalProject_*.mk, incl. ExternalProject_libnumbertext.mk. This
mess should be cleaned up.)
(It looks like a libstdc++ bug to me that such instances of _NFA with different
members due to debug mode nevertheless have the same mangled names.)
Change-Id: I92a41a39c5fe6ae5eb71855e32d929690219f1d1
...as discussed in 371cc81bd9 "external/liborcus:
Fix Linux RPATH:"
* When an external module produces multiple libraries (that we all install) that
depend on each other, they need to contain $ORIGIN in RPATH (strictly
speaking, those that do not depend on any other libraries from the module
would not need that, but it is harmless and easier to do that way).
* When an external module's libraries depend on other external modules'
libraries, and (at least some of) those other external modules are not
configuread as --with-system-*, they need to contain $ORIGIN in RPATH (again,
for simplicity, some libraries may get that even if they would not strictly
need it).
* Try to outsmart the external modules' libtool instances to not add (ultimately
bogus) paths to RPATH for dependencies on libraries from external modules
(either from the same module, or from anohter module not configured as
--with-system-*). The only time we do not outsmart libtool, and instead rely
on it (hopefully?) doing the right thing is when a given external modules'
libraries depend on libraries from excatly one other external module, and the
latter is configured as --with-system-*.
* That outsmarting means that if an external library depends both on external
libraries provided by modules not configured as --with-system-* (so RPATH
contains $ORIGIN, and the outsmarting is not suppressed) and on external
libraries provided by modules configured as --with-system-*: Then if the
latter are in unusual locations on the system that would require an RPATH
entry (which might be provided via the corresponding "pkg-config --libs", say,
and presumably would be honoured by libtool if we did not outsmart it), then
those paths are now erroneously missing from RPATH.
* That outsmarting also causes linking of some utility applications in module
redland to fail, but those are ultimately unused, so cut them off by patching
their respective sub-directory Makefile.in.
Change-Id: Iec05b3568fbcf04987018322c328b769ae4f5dab
Julien Nabet