f447a0a7079619f0d650084df192781cca9fd826 Remove program options from build system (Chun Kuan Lee)
11588c639e8912f1b28e981c1a2a0e4306dbd093 Replace boost program_options (Chun Kuan Lee)
Pull request description:
Concept from #12744, but without parsing negated options.
Tree-SHA512: 7f418744bb8934e313d77a5f162633746ef5d043de802b9c9cd9f7c1842e7e566eb5f171cd9e2cc13317281b2449c6fbd553fa4f09b837e6af2f5d2b2aabdca2
50037e97d11356218c4b36767232e47b74742b0b depends: fix boost mac cross build with clang 9+ (Cory Fields)
Pull request description:
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. Those changes look sane at a glance.
ACKs for top commit:
fanquake:
ACK 50037e97d11356218c4b36767232e47b74742b0b - tested on on macOS, will wait for the gitian build.
Tree-SHA512: eac1f353513a445add6fbece7fc78dd3dbdde5e2219bfb7739b82f40bb14de449667a94d2e303d43c67d9b38e7ceb0ba5f0d8fe20b40be2017b1ca0875467c2c
2620e24b83d16bf0f2bfe360dee1e98b4be59ca5 [depends] boost: update to 1.70 (Sjors Provoost)
Pull request description:
Version [1.70](https://www.boost.org/users/history/version_1_70_0.html) is most recent.
Versions needed for:
* 1.66: #12557: fixes the single arm64 configuration ([06ee5b5](06ee5b54ef))
ACKs for commit 2620e2:
Tree-SHA512: 6e0174f1d92c2c24314c0689d4809e048914f8f42d17aa73799f5ee232169e0dd0ed71f5f973903c44c08309f2837c629c493f15e5c31ec6c7bd1daae5f3b25f
* build: Enable C++11 build, require C++11 compiler
Implements #6211.
* depends: use c++11
* build: update ax_cxx_compile_stdcxx to serial 4
* build: force a c++ standard to be specified
Newer compilers may switch to newer standards by default. For example, gcc6
uses std=gnu++14 by default.
* c++11: fix libbdb build against libc++ in c++11 mode
atomic_init clashes with
* c++11: CAccountingEntry must be defined before use in a list
c++11ism. This fixes builds against libc++.
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
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.
