/xmerge/

<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
  8bd6bf93b7711a7ac7c5cbd7c3bb980481570ebd "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>

upload boost 1.63.0 2017-02-03T08:17:06+00:00 David Tardon dtardon@redhat.com 2017-02-01T11:49:48+00:00 2c1ae441892da3a40cde3a7a796e97cbe9f1da2a Change-Id: I7f896bb9650f68626b4bcfe96c9c41fafeab436a Reviewed-on: https://gerrit.libreoffice.org/33827 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: I7f896bb9650f68626b4bcfe96c9c41fafeab436a
Reviewed-on: https://gerrit.libreoffice.org/33827
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

boost: warning-patch-ectomy 2016-05-30T15:34:51+00:00 Michael Stahl mstahl@redhat.com 2016-05-27T14:24:33+00:00 e5c6574f5df8d2a5914beb03dce604beb8d62ee8 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>

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>

external/boost: Visible function type RTTI for Clang -fsanitize=function 2015-01-26T14:17:29+00:00 Stephan Bergmann sbergman@redhat.com 2015-01-26T14:04:19+00:00 875dc064aa3533dcc41416166ba957c02f81f0bf Change-Id: I6a1ab01bbe5cd128b132c3f6dde4b520ddb4c373

Change-Id: I6a1ab01bbe5cd128b132c3f6dde4b520ddb4c373