- The patches `iostreams-106.patch` and `signals2-noise.patch` were
incorporated into Boost 1.75.
- The allocator access deprecation issue was fixed in Boost 1.76.
Closeszcash/zcash#4945.
C++17 deprecated the two-argument version of std::allocator::allocate.
Starting with 11.0, libc++ enforces these deprecations, which causes
warnings from the Boost headers, and since we require native Linux
builds to be warning-free, this breaks CI.
Boost addressed this issue for MSVC in 1.75; the patch in this commit
forces Clang to be handled in the same way.
Previously, we specified the target-os in the toolset (and sometimes
used the wrong command line flags), now we have a clear separation,
which is favored by ./bootstrap.sh and ./b2.
This means that all supported OSes will specify the correct target-os=
and toolset= on the command line.
b2 will pickup our user-config.jam just fine, however, bootstrap.sh has
its own toolset autodetect mechanism, which doesn't GAF about our
user-config.jam
Zcash: This also reverts b6d0996cec which
fixes a PIE linking error, but likely breaks FreeBSD build support.
All other mk files use the package variable consistently except for the two instances here, which have always been here, since depends was introduced in 0.10.
The ancient "darwin-4.9.1" profile has long been used to match against
clang, which prior to version 9, reported 4.9.1 as its version when
invoking "clang++ -dumpversion". Presumably this was a historical
compatibility quirk related to Apple's switch from gcc to clang.
This was "fixed" in clang 9.0, so that -dumpversion reports the real
version. Unfortunately that had the side-effect of breaking the
(brittle) boost compiler detection.
Move to the seemingly more-correct "clang-darwin" profile, which passes
the checks and builds correctly.
Also switch to using ar rather than libtool for archiving, as it's what
the clang-darwin profile expects to be using.
Note that because this is using a different profile, some of the final
command-line arguments end up changing. The changes look sane at a
glance.
This removes the paches iostreams-106.patch and signals2-noise.patch
which have been incorporated into boost 1.75. Also, this further
postpones updates to native_clank, libcxx and native_ccache.
Clang is used for compiling C/C++ dependencies, as well as the Zcash
binaries themselves. GCC is still required for compiling native
toolchain dependencies (such as ccache).
- The old patch is no longer necessary because of this upstream fix:
https://github.com/boostorg/build/pull/560
- Boost 1.72 removed a <deque> from an include, which exposed a missing
include in src/httpserver.cpp.
- Boost 1.73 moved function placeholders into the boost::placeholders
namespace.
- The new patch is a fix from just after Boost 1.74 was released, fixing
a warning that was missed.
This reverts commit 734e594c2c.
It appears that this was fixing a single issue with the FreeBSD build,
while b6d0996cec addressed the underlying
cause. However, the change in this commit overrides the underlying fix
when cross-compiling for Darwin.
Per the Boost.Build documentation, user-config.jam is supposed to only
be located in the user's home directory, and this appears to be enforced
on FreeBSD.
Boost assumes variadic templates are always available in GCC 4.4+, but
they aren't since we don't build with -std=c++11.
This applies the patch that fixed the issue in boost 1.57:
eec8085549
See also: https://svn.boost.org/trac/boost/ticket/10500
Github-Pull: #6280
Rebased-From: b19a88b2a0e7bd9ef603055bc8e1ef058673025d
tl;dr: This solves boost visibility problems for default/release build configs
on non-Linux platforms.
When Bitcoin builds against boost's header-only classes, it ends up with
objects containing symbols that the upstream boost libs also have. Since
Bitcoin builds by default with hidden symbol visibility, it can end up trying
to link against a copy of the same symbols with default visibility.
This is not a problem on Linux because 3rd party static libs are un-exported
by default (--exclude-libs,ALL), but that is not available for MinGW and OSX.
Those platforms (and maybe others?) end up confused about which version to use.
The OSX linker spews hundreds of: "ld: warning: direct access in <foo> to
global weak symbol guard variable for <bar> means the weak symbol cannot be
overridden at runtime. This was likely caused by different translation units
being compiled with different visibility settings."
MinGW's linker complains similarly.
Since the default symbol visibility for Bitcoin is hidden and releases are
built that way as well, build Boost with hidden visibility. Linux builds Boost
this way also, but only for the sake of continuity.
This means that the linker confusion logic is reversed, so the problem will
will now be encountered if Bitcoin is built with --disable-reduce-exports, but
that's better than the current situation.
Kris Nuttycombe
Jack Grigg
Daira Hopwood
Carl Dong
Peter Bushnell
Cory Fields
Alex Wied
Kris Nuttycombe
Dimitris Apostolou
Larry Ruane
Taylor Hornby
Simon
rofl0r
Nathan Wilcox
Jacob Welsh