<https://dev-www.libreoffice.org/src/boost_1_80_0.tar.xz> has been generated (on
Fedora 36) with
> $ wget https://boostorg.jfrog.io/artifactory/main/release/1.80.0/source/boost_1_80_0.tar.bz2
> $ printf '1e19565d82e43bc59209a168f5ac899d3ba471d55c7610c677d4ccf2c9c500c0 boost_1_80_0.tar.bz2' | sha256sum -c # cf. <https://www.boost.org/users/history/version_1_80_0.html>
> boost_1_80_0.tar.bz2: OK
> $ external/boost/repack_tarball.sh boost_1_80_0.tar.bz2
> Unpacking boost_1_80_0.tar.bz2 ...
> Removing unnecessary files ...
> Creating boost_1_80_0.tar.xz ...
> Cleaning up ...
> 322e567e98c466c0aa0e380ed8c647552fe4af48998648428f1b5f0c8eff4666 boost_1_80_0.tar.xz
> Done.
* In StaticLibrary_boost_filesystem,
<https://github.com/boostorg/filesystem/commit/36cf9aaf816a39dce3d32e2bfe09e214d7f3ab64>
"Updated protection of remove_all against CVE-2022-21658 on POSIX" had
introduced uses of certain POSIX *at functions (like utimensat) conditionally on
some new BOOST_FILESYSTEM_HAS_POSIX_AT_APIS, to be discovered by
workdir/UnpackedTarball/boost/libs/filesystem/CMakeLists.txt which we don't run.
At least AT_NO_AUTOMOUNT, as used in
workdir/UnpackedTarball/boost/libs/filesystem/src/operations.cpp, appears to be
unavailable on the macOS baseline, but otherwise assume that all that POSIX
functionality is available on all other non-Windows baselines and hardcode that
in external/boost/StaticLibrary_boost_filesystem.mk. (If it turns out that we
need to exclude some more platforms there, we /might/ need to backport
<https://github.com/boostorg/filesystem/commit/5864f397ccad30f6e73221b90bdac57a303b9752>
"Fixed a missing include on POSIX systems that don't support *at APIs" from the
develop branch towards Boost 1.81.)
* In StaticLibrary_boost_locale,
<https://github.com/boostorg/locale/commit/41868c62a0519799696b544518f1efd831ff71c2>
"Support systems without implicit include path" had moved source files around
(and then would have failed with
> workdir/UnpackedTarball/boost/libs/locale/src/boost/locale/shared/mo_lambda.cpp:7:10: fatal error: 'boost/locale/shared/mo_lambda.hpp' file not found
> #include "boost/locale/shared/mo_lambda.hpp"
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
etc. without the additional -I option).
* Some Clang builds would have started to fail with
> In file included from desktop/qa/unit/desktop-lok-init.cxx:19:
> In file included from desktop/inc/lib/init.hxx:20:
> In file included from workdir/UnpackedTarball/boost/boost/container/flat_map.hpp:26:
> workdir/UnpackedTarball/boost/boost/container/new_allocator.hpp:168:12: error: '__cpp_sized_deallocation' is not defined, evaluates to 0 [-Werror,-Wundef]
> # if __cpp_sized_deallocation
> ^
so add another external/boost/include/ wrapper.
Change-Id: I5e53f7ddab07eadba9bdf653acad571f50517b46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138511
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
More exotic locales like es-419 cannot be parsed by boost, so we
fall-back to the default encoding. This avoids an exception:
invalid_charset_error of the form:
"Invalid or unsupported charset:us-ascii or UTF-8"
for this case.
Change-Id: I6796dd893ec774b221956ea9febbcc19495d47b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130102
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Stephan Bergmann