Clang's download path includes its version, but LLVM doesn't always
publish every package for every version, so we need to support multiple
versions.
Fixeszcash/zcash#4954.
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.
We want to supply well-known vars to ./configure scripts to do with as
they please. However, we do _not_ want to override these well-known vars
at make-time as certain build systems expect a self-mangled version of
these well-known vars.
For example, freetype and bdb will prepend `libtool --mode=compile' to
CC and CXX, which, if we override CC on the command line at make-time,
will break the build.
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.
Add support for FreeBSD 12
The pre-built binaries for clang 8 on FreeBSD do not ship with `libc++api`, so `libcxxrt` from the base system is used instead.
Please ensure this checklist is followed for any pull requests for this repo. This checklist must be checked by both the PR creator and by anyone who reviews the PR.
* [ ] Relevant documentation for this PR has to be completed and reviewed by @mdr0id before the PR can be merged
* [ ] A test plan for the PR must be documented in the PR notes and included in the test plan for the next regular release
As a note, all buildbot tests need to be passing and all appropriate code reviews need to be done before this PR can be merged
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.
The sense of the test was accidentally inverted in my change to #4733.
The message should be shown if any of the files exist but have an incorrect checksum.
We also now correctly handle the case where there are no package source files.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
While initially fetching packages, I saw `sh: test:` error messages in the make output for only two packages.
However, it appears all packages are correctly fetched.
I tested this patch manually by running these three tests against the `v4.0.0` tag and then with this patch.
In all 6 cases I visually inspected the output.
1. Starting with a pre-downloaded source cash, run the `download` target.
2. Remove an archive from a multi-archive package, then rerun `download`.
3. Alter a hash to cause a hash mismatch condition, then rerun `download`.
I believe after each step both with and without this patch the resulting source cache should be identical
(except for filesystem timestamps).
Co-authored-by: Nathan Wilcox <nathan@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
For mingw32:
- We use the binaries provided by MSYS2, which do not go back as far as
libc++ 8. We use libc++ 9 here, matching the LLVM version we will be
switching to in a subsequent commit (to match the LLVM version used by
Rust 1.44). We manually specify the path to the libc++ headers,
because they don't match the headers used by Clang itself.
- We now require at least mingw-w64 6.0.0, which fixes two Clang
compilation bugs:
- 1bd66b53be
- 82b169c573
Darwin is ignored, as the Xcode SDK includes libc++.
For all other targets, we use the static libraries included in Clang
releases. We reuse the files we downloaded in native_clang for native
compilation, instead of fetching the archive twice.
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).