1aaaaa078b fuzz: Drop unused workaround after Apple-Clang bump (MarcoFalke)
fadad7a494 Drop support for EOL macOS 13 (MarcoFalke)
Pull request description:
Now that macOS 13 is EOL (https://en.wikipedia.org/wiki/MacOS_Ventura), it seems odd to still support it.
(macOS Ventura 13.7.8 received its final security update on 20 Aug 2025: https://support.apple.com/en-us/100100)
This patch will only be released in version 31.x, another 6 months out from now.
So:
* Update the depends build and release note template to drop EOL macOS 13.
* As a result, update the earliest Xcode to version 16 in CI.
* Also, bump the macOS CI runner to version 15, to avoid issues when version 14 will be at its EOL in about 1 year.
This also allows to drop a small workaround in the fuzz tests and unlocks libcpp hardening (https://github.com/bitcoin/bitcoin/pull/33462)
ACKs for top commit:
stickies-v:
re-ACK 1aaaaa078b
l0rinc:
code review ACK 1aaaaa078b
hodlinator:
re-ACK 1aaaaa078b
hebasto:
ACK 1aaaaa078b.
Tree-SHA512: 6d247a8432ef8ea8c6ff2a221472b278f8344346b172980299507f9898bb9e8e16480c128b1f4ca692bcbcc393da2b2fd6895ac5f118bc09e0f30f910529d20c
The https://fukuchi.org/ homepage no longer links to the source tarball,
and previously available files appear to have been removed. The homepage
now instructs users to download source tarballs from the GitHub releases
page instead.
The diff between the source trees is immaterial.
This causes IPC binaries (bitcoin-node, bitcoin-gui) to be included
in releases.
The effect on CI is that this causes more depends builds to build IPC
binaries, but still the only build running functional tests with them
is the i686_multiprocess one.
Except for Windows.
The per-host flag variables hold platform-specific defaults that are ignored
when flag environment variables are set, so it was wrong for them to contain
-std options relied on by package definitions.
Additionally, these flags (-pipe and -std=xx) will no longer be passed into
the CMake build, meaning less duplication in the build summary.
Pulled out of #31920.
f5647c6c5a depends: fix libevent _WIN32_WINNT usage (fanquake)
Pull request description:
Starting with version 13.x, the mingw headers will define the value of
`NTDDI_VERSION`, based on the value of `_WIN32_WINNT`, if that version is <
Windows 10. Given that libevent was undefining our `_WIN32_WINNT`, and
redefining it to a value < Windows 10 (`0x0501`), `NTDDI_VERSION` was also
being defined to that value, leading to functions not being exposed in
the mingw-w64 headers; see here: 9c2668ef77/mingw-w64-headers/include/iphlpapi.h (L36-L41).
Imports a commit from usptream ([a14ff91254f40cf36e0fee199e26fb11260fab49](a14ff91254)).
Fixes#32707.
ACKs for top commit:
willcl-ark:
crACK f5647c6c5a
Tree-SHA512: eb429457a4af6191dd27ef3d1087667c5304ff0f49d4c6824883651e3c2dbab5d9784fa1f170402f23cd9238005c5214e0a71a4160562a59dfa35618dc702132
Starting with version 13.x, the mingw headers will define the value of
NTDDI_VERSION, based on the value of _WIN32_WINNT, if that version is <
Windows 10. Given that libevent was undefining our _WIN32_WINNT, and
redefining it to a value < Windows 10 (0x0501), NTDDI_VERSION was also
being defined to that value, leading to functions not being exposed in
the mingw-w64 headers; see here:
9c2668ef77/mingw-w64-headers/include/iphlpapi.h (L36-L41).
Imports a commit from usptream (a14ff91254f40cf36e0fee199e26fb11260fab49).
Fixes#32707.
When using CMake policies 3.14 and below, the `export(PACKAGE)` command
by default populates the user package registry, which is stored outside
the build tree. Setting the `CMAKE_EXPORT_NO_PACKAGE_REGISTRY` variable
disables this side effect.
In CMake 3.15 and later, this behavior is disabled by default, and the
variable has no effect.
4f10a57671 depends: Override host compilers for FreeBSD and OpenBSD (Hennadii Stepanov)
Pull request description:
When building depends on FreeBSD/OpenBSD `aarch64`, the host compilers default to `default_host_{CC,CXX}`, which resolves to `gcc`/`g++`. This is incorrect on these systems, where Clang is the default system compiler.
To ensure proper compiler selection, this PR adopts the same approach used for `darwin`:c1d4253d31/depends/builders/darwin.mk (L12-L14)
Fixes https://github.com/bitcoin/bitcoin/issues/32691.
ACKs for top commit:
Sjors:
ACK 4f10a57671
Tree-SHA512: 66ace60b63671f2ab7facb84776298e1489aa0a984559c9a22323adaaedcc86f67158078b18c333cb7bdc2b17a4573e321ee7361596bc941db060c5659014069
173394d951 depends: Build `qt` package for FreeBSD hosts (Hennadii Stepanov)
Pull request description:
This PR continues the work started in https://github.com/bitcoin/bitcoin/pull/23948.
Here is an excerpt from the log:
```
$ ./build/bin/bitcoin-qt -printtoconsole
2025-06-12T01:06:56Z Bitcoin Core version v29.99.0-15de25ba2a28 (release build)
2025-06-12T01:06:56Z Qt 6.7.3 (static), plugin=xcb
2025-06-12T01:06:56Z Static plugins:
2025-06-12T01:06:56Z QMinimalIntegrationPlugin, version 395008
2025-06-12T01:06:56Z QXcbIntegrationPlugin, version 395008
2025-06-12T01:06:56Z Style: fusion / QFusionStyle
2025-06-12T01:06:56Z System: FreeBSD 14.3-RELEASE, x86_64-little_endian-lp64
```
And here are the screenshots:


ACKs for top commit:
vasild:
ACK 173394d951
Tree-SHA512: 42a0bd11e4ef1a23efcfe6c4ab179dc667a076e65060891ce8358b3fe78de4e3ea33f975387d4236cc2ac620e2935b0a29c278065a47f038c66658106bf36755
This has a few advantages over the old method of simply copying headers:
- Installs proper cmake files which can be picked up by our buildsystem
- Only installs necessary headers, not all of boost
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
Nix patches cmake to remove the root directory `/` from
`CMAKE_SYSTEM_PREFIX_PATH`:
428b49b28e/pkgs/by-name/cm/cmake/001-search-path.diff (L10)
Without this, and when using the toolchain for depends builds, cmake's
`find_path()` and `find_package()` do not know where to find
dependencies, causing issues like:
https://github.com/bitcoin/bitcoin/issues/32428
Adding this path back via CMAKE_PREFIX_PATH is harmless on other
systems, and fixes the toolchain for Nix users.
We append the `/` dir a maximum of once, as the toolchain may be called
repeatedly during builds.
Co-authored-by: Russell Yanofsky <russ@yanofsky.org>
Co-authored-by: josibake <josibake@protonmail.com>
d7c37906e7 build: patch cmake min version on freetype (josibake)
Pull request description:
## Problem
While doing a depends build with CMake 4.0.1, I got the following error:
```
Extracting freetype...
/root/bitcoin/depends/sources/freetype-2.11.0.tar.xz: OK
Preprocessing freetype...
Configuring freetype...
CMake Error at CMakeLists.txt:100 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
-- Configuring incomplete, errors occurred!
make: *** [funcs.mk:343: /root/bitcoin/depends/x86_64-pc-linux-gnu/.freetype_stamp_configured] Error 1
make: Leaving directory '/root/bitcoin/depends'
```
.. which led me to https://cmake.org/cmake/help/latest/release/4.0.html#deprecated-and-removed-features, which states compatibility with CMake versions less than 3.5 has been removed in 4.0.
## Fix
Based on the suggestion from the error message (and from reading the CMake docs), I added `-DCMAKE_POLICY_VERSION_MINIMUM=3.22`. I picked `3.22` (as opposed to 3.5) since that is the minimum version of CMake we specify in `doc/dependencies.md`. Would be nice if there was a way to pipe the min version in as a variable (since presumably we'd want to update this to be in lock step with the minimum CMake version of the whole project), but I couldn't think of a simple way to do this. Open to suggestions on a more robust way to do this if this is deemed too brittle.
ACKs for top commit:
fanquake:
ACK d7c37906e7
hebasto:
ACK d7c37906e7. Tested on Ubuntu 25.04 with both cmake 4.0.2 and the default cmake 3.31.6.
Tree-SHA512: fb664ec73bfffc504f1dcc9076072307f443d056d14325de41c4a29f3ee4077f1922e79b5895b49e7354f45ad6a35be4973c153c2baf3376df6c0d209efc9c54
8713e8060d depends: fix SHA256SUM command on OpenBSD (use GNU mode output) (Sebastian Falbesoner)
2d938720bd depends: add patch to fix capnp build on OpenBSD (Sebastian Falbesoner)
Pull request description:
This PR fixes the multiprocess depends build for OpenBSD by applying upstream patch https://github.com/capnproto/capnproto/pull/2308 and switching the SHA256SUM command to output hash sums in the expected format (the default is BSD format [1], but we need GNU format [2], see commit message for details). Note that the hashing issue is only prevailing for packages defining the `$(package)_local_dir` variable (introduced in 5d105fb8c3, part of #31741), where the following line of the `fetch_local_dir_sha256` function leads to the wrong output:
ae024137bd/depends/funcs.mk (L57)
The first commit can be replaced with a simple capnp version bump once this is available in a release.
Tested on OpenBSD 7.7 (x86_64) via
```
$ gmake -C depends MULTIPROCESS=1 NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_QR=1 NO_WALLET=1 NO_ZMQ=1 NO_USDT=1
```
[1] example output: `SHA256 (/home/thestack/.vimrc) = 6ba69d100e8c5ca0488ded6293d4e5f740a6a5d5ace96cbcf0599c18d27389e4`
[2] example output: `6ba69d100e8c5ca0488ded6293d4e5f740a6a5d5ace96cbcf0599c18d27389e4 /home/thestack/.vimrc`
ACKs for top commit:
Sjors:
ACK 8713e8060d
hebasto:
ACK 8713e8060d.
fanquake:
ACK 8713e8060d
Tree-SHA512: 178b8b41156e1f1eea101849110167d2636c3093b6a68c88a91a994f0750831aa02e415eb2793c522682c92cb3085de025300e0e2dee894e112dd7e1f495cc08
When building depends on FreeBSD/OpenBSD `aarch64`, the host compilers
default to `default_host_{CC,CXX}`, which resolves to `gcc`/`g++`. This
is incorrect on these systems, where Clang is the default system
compiler.
On OpenBSD, the `sha256` command by default outputs hashsums on files in
"BSD" mode, looking like this:
$ sha256 ~/.vimrc
SHA256 (/home/thestack/.vimrc) = 6ba69d100e8c5ca0488ded6293d4e5f740a6a5d5ace96cbcf0599c18d27389e4
This is not compatible with our depends commands, which expect the
hashes to be on the first column (to be extracted via `cut -d" " -f1`).
Fix this by switching to GNU mode output, looking like this:
$ sha256 -r ~/.vimrc
6ba69d100e8c5ca0488ded6293d4e5f740a6a5d5ace96cbcf0599c18d27389e4 /home/thestack/.vimrc
Without this change, the multiprocess depends build fails with the following output:
$ gmake -C depends MULTIPROCESS=1 NO_BOOST=1 NO_LIBEVENT=1 NO_QT=1 NO_QR=1 NO_WALLET=1 NO_ZMQ=1 NO_USDT=1
[ ..... ]
Extracting native_libmultiprocess...
sha256: /home/thestack/bitcoin/depends/work/build/x86_64-unknown-openbsd7.7/native_libmultiprocess/-2bc902f4693/.src-ipc-libmultiprocess.tar.hash: no properly formatted checksum lines found
gmake: *** [funcs.mk:342: /home/thestack/bitcoin/depends/work/build/x86_64-unknown-openbsd7.7/native_libmultiprocess/-2bc902f4693/.stamp_extracted] Error 1
df9ebbf659 depends: use "mkdir -p" when installing xproto (fanquake)
Pull request description:
It looks like the mkdir detection in xproto is broken on Alpine. Ensure we always use `mkdir -p`.
Fixes#32494.
ACKs for top commit:
hebasto:
ACK df9ebbf659, I have reviewed the code and it looks OK.
janb84:
ACK df9ebbf659
willcl-ark:
ACK df9ebbf659
Tree-SHA512: 0f23b1096ffdf5ffa13115665dc42b65835b78bb0ab04a8be8f210980356953ab518e1273302fe4c9239361201f4f9ac737c0ebf10625f4817f81b65b3b25572
415650cea9 guix: move *-check.py scripts under contrib/guix (fanquake)
Pull request description:
These scripts are not meant for general developer usage. They are for use on the release binaries, which have been compiled in an environment that makes various assumptions in regards to c library, compiler options, hardening options, dependency patching etc.
Anyone is free to run these scripts against self-compiled binaries, but this isn't something we want to modify/generalize the scripts to support.
ACKs for top commit:
laanwj:
Code review ACK 415650cea9
TheCharlatan:
ACK 415650cea9
Tree-SHA512: 469cc5da9df014b4a9dc39080f31c3283641691209497cdb7cc5dc4767681a7f4b67425768e81838153ce39a26547ed94cd3be4dc27352d33960765bfac9d0e5
These scripts are not meant for general developer usage. They are for
use on the release binaries, which have been compiled in an environment
that makes various assumptions in regards to c library, compiler
options, hardening options, patching etc.
Using helper variables has two issues:
1. They contaminate the global namespace of the main build script.
2. They can be used as `set(var)`, effectively exposing a cache variable
`var`, which makes the toolchain file susceptible to the build
environment.
Native compilation is explained before cross-compilation. Move
install and (g)make steps up.
In the Configuring section, use Linux native compilation as the
example instead of Windows cross-compile.
With newly introduced libmultiprocess subtree, there's no need for depends
system to download and track changes to the upstream repository.
Note that adding the libmultiprocess subtree does not allow dropping
libmultiprocess packages from the depends build, because libmultiprocess
includes a code generation tool called mpgen, and in cross-compiled builds,
bitcoin core's cmake build system doesn't have access to a native toolchain and
can't build mpgen itself, so the depends system (or the native environment if
not using depends) needs to supply it.