This makes it easier to use different LLVM point releases for different
hosts (as available), and ensures that `$(package)_major_version` is set
correctly when using a different major release on a Tier 3 platform.
Closeszcash/zcash#6534.
- We update Windows cross-compile builds to 15.0.7 because binaries are
provided for it, but not currently for any other platform we need.
- We update native x84_64 macOS builds to 15.0.4 because no 15.0.6
binaries are provided, and the 15.0.7 ones appear to be targeted at a
newer Darwin version.
- We keep FreeBSD on 14.0.6 because no Clang 15 binaries are provided,
and as FreeBSD is a Tier 3 platform it doesn't block us from upgrading
the remaining platforms.
Previously, they downloaded to filenames that were simply the git hashes
followed by .tar.gz, now this creates
`native_cctools_55562e4073dea0fbfd0b20e0bf69ffe6390c7f97.tar.gz` and
`native_cctools_libtapi_3efb201881e7a76a21e0554906cf306432539cef.tar.gz`
Note that those are the filenames that must exist on download.z.cash
as well, since the alternate URLs fetched refer to the
*destination filename* and not the original (here, github) filename.
The new URLs (with `archive/ref/tags`) are good for tag-based references
so we leave them alone, and only revert the hash-based URLs to GitHub
URLs which doesn't 404 and give us files with the expected hashes today.
Currently, the three repos in question (`cctools-port`, `apple-libtapi`,
and `expected`) do not have usable tags/releases we can use instead of
the hashes.
We will also upload correct versions of those files to the
download.z.cash server (with the correct filenames) so if there's
another issue with hash stability (like there was on 30 January 2023
https://github.com/orgs/community/discussions/46034)
it won't instantly break the build.
After #19685 started setting LDFLAGS, the INSTALL_RPATH_USE_LINK_PATH cmake
option used in the libmultiprocess build no longer works, so it is neccessary
to set CMAKE_INSTALL_RPATH as a fallback.
It's unclear currently whether the bad interaction between
INSTALL_RPATH_USE_LINK_PATH and LDFLAGS is a bug, but the issue is reported:
https://github.com/bitcoin/bitcoin/issues/19981#issuecomment-696680877https://discourse.cmake.org/t/install-rpath-use-link-path-not-working-when-cmake-exe-linker-flags-ldflags-is-set/1892
Commands useful for building / testing this change
make -C depends MULTIPROCESS=1 print-libmultiprocess_cmake
make -C depends MULTIPROCESS=1 print-native_libmultiprocess_cmake
make -C depends MULTIPROCESS=1 HOST=x86_64-apple-darwin16 print-libmultiprocess_cmake
rm -rvf depends/x86_64-pc-linux-gnu/native depends/work/staging depends/work/build
make -C depends MULTIPROCESS=1 V=1 native_libmultiprocess_staged
for f in `find -name mpgen`; do echo == $f ==; readelf -d $f | grep -i path; done
make -C depends MULTIPROCESS=1 V=1 native_libmultiprocess_built
find -name CMakeCache.txt
Fixes#19981
(cherry picked from commit bitcoin/bitcoin@7d0271b5c3)
for operator->, operator*, and error(). Make these into assertion failures
(this still conforms to the proposal).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
In practice we are using 14.0.0 in most cases, as the LLVM Project have
not published Ubuntu binaries for any point release after 14.0.0 (which
we are using here).
We could also generate this in the main build with `cxxbridge --header`,
but we have the source from vendoring `cxxbridge`, and this simplifies
the automake integration slightly.
Jack Grigg
Miodrag Popović
Jack Grigg
Daira Hopwood
sasha
Kris Nuttycombe
Jack Grigg
Russell Yanofsky
Carl Dong
Greg Pfeil
idm