<https://dev-www.libreoffice.org/src/boost_1_69_0.tar.bz2> is a copy of
<https://dl.bintray.com/boostorg/release/1.69.0/source/boost_1_69_0.tar.bz2>,
SHA256 hash as given at <https://www.boost.org/users/download/>.
* removed from external/boost/include/boost/ those files that are no longer
present in workdir/UnpackedTarball/boost/boost/
* the shrunk external/boost/rtti.patch.0 can probably be removed completely in a
follow-up commit
* the patch to libs/filesystem/src/operations.cpp in
external/boost/boost-android-unified.patch.1 no longer applied, and appears to
be no longer necessary anyway (seeing a working build without it of
--with-distro=LibreOfficeAndroid and NDK r16b); but with the non-standard
Clang 5.0.300080 from NDK r16b, the build now caused failures like
> workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:36:11: error: class template partial specialization contains a template parameter that cannot be deduced; this partial specialization will never be used [-Wunusable-partial-specialization]
> struct is_function<Ret BOOST_TT_DEF_CALL(Args...)BOOST_TT_NOEXCEPT_DECL> : public true_type {};
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:35:38: note: non-deducible template parameter 'NE'
> template <class Ret, class...Args BOOST_TT_NOEXCEPT_PARAM>
> ^
> workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:22:40: note: expanded from macro 'BOOST_TT_NOEXCEPT_PARAM'
> #define BOOST_TT_NOEXCEPT_PARAM , bool NE
> ^
showing that that version of Clang has the same problem handling noexcept(b)
as a deduced template parameter as MSVC has, as already supported by the code
* new external/boost/sse.patch.0 needed on Windows x86 to silence errors like
> C:\cygwin\home\tdf\lode\jenkins\workspace\gerrit_windows\workdir\UnpackedTarball\boost\boost/type_traits/detail/is_function_cxx_11.hpp(111): error C2215: '__vectorcall' cannot be used with '/arch:SSE'
(<https://ci.libreoffice.org/job/gerrit_windows/26117/>); according to
<https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
?view=vs-2017>: "_M_IX86_FP Defined as an integer literal value that indicates
the /arch compiler option that was set, or the default. This macro is always
defined when the compilation target is an x86 processor. Otherwise, undefined.
When defined, the value is: [...] 1 if the /arch:SSE compiler option was set."
and we specify /arch:SSE explicitly for Windows x86 since
8bd6bf93b7 "fdo#82430: configure: MSVC build:
avoid using SSE2 instructions"
* boost::logic::tribool conversion operator to bool is explicit now
Change-Id: Iea49560d734f545539f062dce46740fbf812dd84
Reviewed-on: https://gerrit.libreoffice.org/66189
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Upstream maintainers, with few exceptions, generally don't care about
warnings in boost headers, hence we re-base our warning fix patches on
every upgrade, which is a pointless exercise in frustration.
Most of the patches are for GCC/Clang warnings, where we could use
-isystem to suppress the warnings (with corresponding hacks in the build
system, because -isystem also disables dependency generation) - but
clang-cl does not support -isystem.
So generate a bunch of wrapper headers into external/boost/include, that
disable all known warnings and use #include_next to get the real boost
header. This allows us to get rid of most of the existing patches.
There is however a bug in GCC that preprocessor warnings like -Wundef
cannot be disabled with a #pragma, so those patches cannot be removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
Change-Id: I2992bf4a463015f1140489df867bd80757f84541
Reviewed-on: https://gerrit.libreoffice.org/25563
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Stephan Bergmann