...for C++17 and beyond with
<https://github.com/llvm/llvm-project/commit/681cde7dd8b5613dbafc9ca54e0288477f946be3>
"[libc++] Complete the implementation of N4190". (Unless explicitly opted-in
with _LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION. This is similar to the
MSVC standard library needing _HAS_AUTO_PTR_ETC=1 to enable those zombie
functions for quite some time now. Only libstdc++ still supports them
unconditionally.)
Most uses of those zombie functions across LibreOffice itself and the bundled
external/* are indirectly within Boost include files. And many (but not all) of
those Boost include files only use those zombie functions conditionally, based
on BOOST_NO_CXX98_FUNCTION_BASE. For the (Dinkumware-derived) MSVC standard
library, workdir/UnpackedTarball/boost/boost/config/stdlib/dinkumware.hpp
already defined BOOST_NO_CXX98_FUNCTION_BASE. So add a patch to define that
also in workdir/UnpackedTarball/boost/boost/config/stdlib/libcpp.hpp (for all of
C++11 and beyond, even if those functions were still available as deprecated in
C++11 and C++14, but which shouldn't make a difference with our C++17 baseline
anyway; only make sure that things still work if those Boost include files ever
get used by code built with gb_CXX03FLAGS). (Patching our bundled
external/boost of course doesn't help when building with such a new libc++ and
--with-system-boost against an unpatched Boost, but lets consider that "not my
problem". Also, one could always use a sledgehammer like passing
CPPFLAGS=-D_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION into gbuild in
such a case.)
Then there are two places that include boost/multi_array.hpp, which indirectly
includes workdir/UnpackedTarball/boost/boost/functional.hpp, which still uses
those zombie functions for non-MSVC builds (at least in the bundled
Boost 1.79.0). Lets do a targeted
_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION in those cases.
(Alternatively, we could patch
workdir/UnpackedTarball/boost/boost/functional.hpp. Also, I decided to make
loplugin:reservedid support the new suppression mechanism, rather than extending
its existing ignorelist even further.)
And then there is external/clucene using those zombie functions even outside of
a Boost include file, so extend the existing hack there that was already needed
for MSVC. (And adapt the accompanying comment: For one, we are unconditionally
"in C++17 mode" by now. And for another, the exact places where
external/clucene uses those functions have apparently changed over time.)
Change-Id: Id0eec3bedcfddae86b16d33c02c7b5d3b3f8a16f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136579
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
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>
...in various places, which is gone by default at least from recent libc++ in
C++17 mode. So bring it back there for now, until Boost is fixed.
Change-Id: I0b3128d114ab2b5693a84bdc7d2b9b9b9b5c3c76
Reviewed-on: https://gerrit.libreoffice.org/45910
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Also regenerated all patches using make icu.genpatch (hence the .1
suffix that indicates the path level) as some hunks did not apply anyway
and all now have the correct offset. Using genpatch may have the future
benefit to yield smaller diffs between different versions of patches.
Also prefixed all patch names with icu4c- for a cleaner listing.
New patches introduced are prefixed with icu4c-59-...
Change-Id: Ia83754b0823839887fce1a1d4ed04f8375b113c2
Reviewed-on: https://gerrit.libreoffice.org/36809
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@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>
Khaled Hosny