glibc 2.33 introduced a new fortification level, _FORTIFY_SOURCE=3.
Which improves the coverage of cases where _FORTIFY_SOURCE can use _chk
functions. For example, using GCC 13 and glibc 2.36 (Fedora Rawhide),
compiling master:
```bash
nm -C src/bitcoind | grep _chk
U __fprintf_chk@GLIBC_2.17
U __memcpy_chk@GLIBC_2.17
U __snprintf_chk@GLIBC_2.17
U __sprintf_chk@GLIBC_2.17
U __stack_chk_fail@GLIBC_2.17
U __stack_chk_guard@GLIBC_2.17
U __vsnprintf_chk@GLIBC_2.17
objdump -d src/bitcoind | grep "_chk@plt" | wc -l
33
```
vs this branch:
```bash
nm -C src/bitcoind | grep _chk
U __fprintf_chk@GLIBC_2.17
U __memcpy_chk@GLIBC_2.17
U __memset_chk@GLIBC_2.17
U __snprintf_chk@GLIBC_2.17
U __sprintf_chk@GLIBC_2.17
U __stack_chk_fail@GLIBC_2.17
U __stack_chk_guard@GLIBC_2.17
U __vsnprintf_chk@GLIBC_2.17
objdump -d src/bitcoind | grep "_chk@plt" | wc -l
61
```
Usage of level 3 requires LLVM/Clang 9+, or GCC 12+. Older
compilers/glibc will still use _FORTIFY_SOURCE=2. For example, in the
glibc we currently use for Linux release builds (2.24), FORTIFY_LEVEL is
determined using the following:
```c
```
so any value > 1 will turn on _FORTIFY_SOURCE=2.
https://sourceware.org/pipermail/libc-alpha/2021-February/122207.htmlhttps://developers.redhat.com/blog/2021/04/16/broadening-compiler-checks-for-buffer-overflows-in-_fortify_source
Even though all other targets are disabled, we still need Boost CPPFLAGS
(use_boost) to compile. This currently works everywhere, except on arm
macOS (where the include path is pretty non-standard), because
generally, the Boost include path is generic, i.e `/usr/include`.
d4c59da8d6 build: Avoid `BOOST_NO_CXX98_FUNCTION_BASE` macro redefinition (Hennadii Stepanov)
Pull request description:
With GCC 12 and Boost 1.81 (from depends) having multiple warnings:
```
In file included from /home/hebasto/bitcoin/depends/x86_64-pc-linux-gnu/include/boost/config.hpp:48:
/home/hebasto/bitcoin/depends/x86_64-pc-linux-gnu/include/boost/config/stdlib/libstdcpp3.hpp:397:9: warning: 'BOOST_NO_CXX98_FUNCTION_BASE' macro redefined [-Wmacro-redefined]
#define BOOST_NO_CXX98_FUNCTION_BASE
^
<command line>:8:9: note: previous definition is here
#define BOOST_NO_CXX98_FUNCTION_BASE 1
^
1 warning generated.
```
This PR fixes those warnings.
Defining of the `BOOST_NO_CXX98_FUNCTION_BASE` macro was introduced in https://github.com/bitcoin/bitcoin/pull/25436, but since https://github.com/boostorg/config/pull/430, it is required to check it before adding.
ACKs for top commit:
fanquake:
ACK d4c59da8d6 - it works now.
Tree-SHA512: 53b9ddcf8dad729638ed41251e30c80f2d7d1ae3ffe47466865834f1f10184fe0881abeb339b3e46c270c3eb11fb63d19ab12cc9461bf5c2be12b4763c1b1c34
d51f0fa4b7 doc: add release notes for 26896 (fanquake)
2b248798d9 build: remove --enable-upnp-default from configure (fanquake)
02f5a5e7b5 build: remove --enable-natpmp-default from configure (fanquake)
25a0e8ba0b Remove configure-time setting of DEFAULT_UPNP (fanquake)
06562e5fa7 Remove configure-time setting of DEFAULT_NATPMP (fanquake)
Pull request description:
This PR removes the `--enable-upnp-default` and `--enable-natpmp-default` options from configure.
It's odd to me that we maintain configure-time options for setting the default port-forwarding runtime state (but no other similar options), and I'm not sure what use-case it satisfies, that can't be achieved by multiple other means. I also doubt that we'll ever restart using these in release builds, or turning on any of this by default.
I think the only scenario these options would be used is when you want to compile your own binaries (we don't use them in Guix), with port-forwarding on by default, but otherwise can't or don't want to use a `.conf` file, can't or don't want to pass command line options at runtime, and also don't want to modify the source code?
ACKs for top commit:
hebasto:
ACK d51f0fa4b7, rebased and comments have been addressed since my recent [review](https://github.com/bitcoin/bitcoin/pull/26896#pullrequestreview-1273910740).
TheCharlatan:
ACK d51f0fa4b7
Tree-SHA512: 481decd8bddd8b03b7319591e3acf189f7b6b96c9a9a8c5bc1a3f8ec00d0b8f9b52d2f5c28a298a2ec947cfe9611cfd184e393ccb2e4e21bfce86ca7d4de60d3
0f883df7a5 build: fix configuring with only bitcoin-util (fanquake)
Pull request description:
Fixes the issue presented in #25037 in a single (easily backportable) diff, with no additional refactoring/changes.
Can be tested with:
```bash
./configure \
--disable-tests \
--disable-bench \
--without-libs \
--without-daemon \
--without-gui \
--disable-fuzz-binary \
--without-utils \
--enable-util-util
```
ACKs for top commit:
TheCharlatan:
tACK 0f883df7a5
hebasto:
ACK 0f883df7a5, tested on Ubuntu 22.04.
Tree-SHA512: 3682712405c360852c4edd90c171e21302154bf8789252c64083974a5c873cf04d97e8721c7916d5b2dafa6acd2b8dc32deecf550e90e03bcbbabbbbf75ce959
2022917223 Add secp256k1_selftest call (Pieter Wuille)
3bfca788b0 Remove explicit enabling of default modules (Pieter Wuille)
4462cb0498 Adapt to libsecp256k1 API changes (Pieter Wuille)
9d47e7b71b Squashed 'src/secp256k1/' changes from 44c2452fd3..21ffe4b22a (Pieter Wuille)
Pull request description:
Now that libsecp256k1 has a release (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021271.html), update the subtree to match it.
The changes themselves are not very impactful for Bitcoin Core, but include:
* It's no longer needed to specify whether contexts are for signing or verification or both (all contexts support everything), so make use of that in this PR.
* Verification operations can use the static context now, removing the need for some infrastructure in pubkey.cpp to make sure a context exists.
* Most modules are now enabled by default, so we can drop explicit enabling for them.
* CI improvements (in particular, MSVC and more recent MacOS)
* Introduction of an internal int128 type, which has no effect for GCC/Clang builds, but enables 128-bit multiplication in MSVC, giving a ~20% speedup there (but still slower than GCC/Clang).
* Release process changes (process documentation, changelog, ...).
ACKs for top commit:
Sjors:
ACK 2022917223, but 4462cb0498 could use more eyes on it.
achow101:
ACK 2022917223
jonasnick:
utACK 2022917223
Tree-SHA512: 8a9fe28852abe74abd6f96fef16a94d5a427b1d99bff4caab1699014d24698aab9b966a5364a46ed1001c07a7c1d825154ed4e6557c7decce952b77330a8616b
Fixes the issue presented in #25037 in a single (easily backportable)
diff, with no additional refactoring/changes.
Can be tested with:
```bash
./configure \
--disable-tests \
--disable-bench \
--without-libs \
--without-daemon \
--without-gui \
--disable-fuzz-binary \
--without-utils \
--enable-util-util
```
These headers are already included in a default set which are checked
early during configure.
We already use at least sys/types.h and unistd.h unconditionally in
configure.
98868633d1 Bugfix: configure: bitcoin-{cli,tx,util} don't need UPnP, NAT-PMP, or ZMQ (Luke Dashjr)
Pull request description:
As with #23345, these other tools likewise don't use various deps.
ACKs for top commit:
achow101:
ACK 98868633d1
Tree-SHA512: 4be056b8e0c9f69834229aa257187457de1bc34214d320b770834e21ecc1f0ca7aa7b9689fba525928947bfabbb461528795f709014fb9618b82f088fe64f271
d216d714aa Revert "build: Use Homebrew's sqlite package if it is available" (fanquake)
Pull request description:
This reverts ee7b84e63c from #20527.
That change was made without any rationale, maybe other than, a brew
installed version might be newer, and that's "better". However when
building from source on macOS, it just results in drastically worse
performance, and issues / confusion like #25724.
The difference in performance can be observed using the example from https://github.com/bitcoin/bitcoin/issues/25724#issuecomment-1213554922,
but minified i.e:
```bash
time src/bitcoin-cli createwallet speedy true
time src/bitcoin-cli importdescriptors '[
{"desc":"raw(00145846369f3d6ba366d6f5a903fb5cf4dca3763c0e)#k9wh6v62","timestamp":"now"},
{"desc":"raw(001420800aabf13f3a4c4ce3ce4c66cecf1d17f21a6e)#6m0hlfh4","timestamp":"now"},
{"desc":"raw(0014c6bf9715e06d73ebf9b3b02d5cc48d24d8bbabc1)#wyavh36r","timestamp":"now"},
{"desc":"raw(00141ba7807b3f46af113beaea5c698428ce7138cd8a)#jctdsups","timestamp":"now"},
{"desc":"raw(00140c1bd27f10fff01b36ddf3c1febaa1acff19b080)#9s6nc3pk","timestamp":"now"},
{"desc":"raw(00141226e31987e4bc2e63c0ee12908f675e40464b20)#9pp7qm39","timestamp":"now"},
{"desc":"raw(0014f73f149f7503960a5e849c6ee7a8a8c336f631cb)#qtkxv9fc","timestamp":"now"},
{"desc":"raw(0014c8ccb4d81ffc769fc5fdd8d7eed69b0e0cae5749)#hn39qayv","timestamp":"now"},
{"desc":"raw(001498565aead2d67a22a6021d55210f2a917fc22169)#6ar3vwsx","timestamp":"now"},
{"desc":"raw(001403013248ac0cd9eabe176cad162cda2a19f771e1)#4m47mukd","timestamp":"now"}
]'
```
Running master, when building from souce and using brew installed
sqlite, this takes ~3.4s. With this PR, the same operation takes ~0.3s.
Resolves the "build from source" portion of #25724. Building from
depends is still not ideal, however I have some other changes that might
help improve things in that case.
Related performance issue reports:
* https://github.com/bitcoindevkit/bdk/issues/749
* https://bitcoin.stackexchange.com/questions/113898/bitcoin-v23-is-10-times-slower-than-v22-on-macos-for-basic-regtest-tests
* https://github.com/bitcoin/bitcoin/issues/25724
* https://github.com/bitcoin/bitcoin/pull/25985#issuecomment-1245942400
ACKs for top commit:
achow101:
ACK d216d714aa
jarolrod:
ACK d216d714aa
hebasto:
ACK d216d714aa, I have reviewed the code and it looks OK, I agree it can be merged. No conflicts with our build [docs](d216d714aa/doc/build-osx.md (descriptor-wallet-support)).
Tree-SHA512: 1bb4b44385b11fa9fe66edd7449278f9e47a6cc679b7111f9adf17db94c34e29c9cceafc917454e134420db40b24b56da29226af6f43e6dbeff822b79b77ed60
We currently perform the same check twice, to put the same set of flags
in two different variables. Split the checks so we test for crc and crypto
extensions independently.
If we don't want to split, we should just delete the second AX_CHECK_COMPILE_FLAG
check, and set ARM_CRC_CXXFLAGS & ARM_CRC_CXXFLAGS at the same time.
We already use a mix of <cstdlib> and stdlib.h unconditionally throughout
the codebase.
Us checking this header also duplicates work already done by autotools.
Currently stdlib.h is checked for 3 times during a ./configure run, after
this change, at least it's only twice.
We already use a mix of <cstdio> and stdio.h unconditionally throughout
the codebase.
Us checking this header also duplicates work already done by autotools.
Currently stdio.h is checked for 3 times during a ./configure run, after
this change, at least it's only twice.
We don't include strings.h anywhere.
This is also already checked for by autoconf, so us checking for it just
means a 3rd existence check during ./configure.
This reverts ee7b84e63c from #20527.
This change was made without any rationale, maybe other than a brew
installed version might be newer, and that's "better". However when
building from source on macOS, it just results in drastically worse
perofrmance, and results in issues / confusions like #25724.
Resolves the "build from source" portion of #25724. Building from
depends is still not ideal, however I have some other changes that might
help improve things in that case.
The difference in performance can be observed using the example from
https://github.com/bitcoin/bitcoin/issues/25724#issuecomment-1213554922,
but minified to only 10 descriptors. i.e:
```bash
time src/bitcoin-cli createwallet speedy true
time src/bitcoin-cli importdescriptors '[
{"desc":"raw(00145846369f3d6ba366d6f5a903fb5cf4dca3763c0e)#k9wh6v62","timestamp":"now"},
{"desc":"raw(001420800aabf13f3a4c4ce3ce4c66cecf1d17f21a6e)#6m0hlfh4","timestamp":"now"},
{"desc":"raw(0014c6bf9715e06d73ebf9b3b02d5cc48d24d8bbabc1)#wyavh36r","timestamp":"now"},
{"desc":"raw(00141ba7807b3f46af113beaea5c698428ce7138cd8a)#jctdsups","timestamp":"now"},
{"desc":"raw(00140c1bd27f10fff01b36ddf3c1febaa1acff19b080)#9s6nc3pk","timestamp":"now"},
{"desc":"raw(00141226e31987e4bc2e63c0ee12908f675e40464b20)#9pp7qm39","timestamp":"now"},
{"desc":"raw(0014f73f149f7503960a5e849c6ee7a8a8c336f631cb)#qtkxv9fc","timestamp":"now"},
{"desc":"raw(0014c8ccb4d81ffc769fc5fdd8d7eed69b0e0cae5749)#hn39qayv","timestamp":"now"},
{"desc":"raw(001498565aead2d67a22a6021d55210f2a917fc22169)#6ar3vwsx","timestamp":"now"},
{"desc":"raw(001403013248ac0cd9eabe176cad162cda2a19f771e1)#4m47mukd","timestamp":"now"}
]'
```
Running master, when building from souce and using brew installed
sqlite, this takes ~3.4s. With this PR, the same operation takes ~0.3s.
8df063e537 build: Fix help string for `--enable-external-signer` configure option (Hennadii Stepanov)
Pull request description:
This PR is a follow up of bitcoin/bitcoin#24065 and fixes the help string according to the actual default value 816ca01650/configure.ac (L324-L327)
ACKs for top commit:
kristapsk:
cr utACK 8df063e537
jarolrod:
ACK 8df063e537
Tree-SHA512: ad3f457a53c9238ddd8ded9efd1224e564e6cb9da8b7ff7733a11e32a7daad5c0f6c6223509218f44944a874470cb0d2447897662eaf4e78c763b30785717c50
9aeeb75cf9 Add symlinks for hardcoded Makefiles in out of tree builds (Pablo Greco)
Pull request description:
When doing out of tree builds, some hardwired Makefiles are not symlinked, which makes it a bit more uncomfortable to run some instances of make.
There's no "real" functionality loss without this patch because the symlinked files are just for quick access to thinks in the main Makefile
ACKs for top commit:
hebasto:
ACK 9aeeb75cf9, tested on Ubuntu 22.04.
Tree-SHA512: 656f73c387584cee34f66b3f95993267a40b915762949c7a84b73ba2ea8d37b7b5850733377110e0110ed2f7da64e6a5f9b303812080fe7815154dbb40c8a44c
Our usage of std::atomic is with it's own exchange function, not
std::atomic_exchange. So we should be looking specifically for that
function.
Additionally, -pthread and -lpthread have an effect on whether -latomic
will be needed, so the atomics check needs to use these flags as well.
This will make the flags in use better match what is actually used when
linking.
This removes the need for -latomic for riscv builds, which resolves a
guix cross architecture reproducibility issue.
Boost conatiner_hash (included via functional -> multi_index) uses
std::unary_function, which was deprecated in C++11, and "removed" in
C++17. It's use causes wanrings with newer compilers, i.e GCC 12.1.
```bash
/bitcoin/depends/aarch64-unknown-linux-gnu/include/boost/container_hash/hash.hpp:131:33:
warning: 'template<class _Arg, class _Result> struct std::unary_function' is deprecated [-Wdeprecated-declarations]
131 | struct hash_base : std::unary_function<T, std::size_t> {};
| ^~~~~~~~~~~~~~
In file included from /usr/include/c++/12/bits/unique_ptr.h:37,
from /usr/include/c++/12/memory:76,
from ./init.h:10,
from init.cpp:10:
/usr/include/c++/12/bits/stl_function.h:117:12: note: declared here
117 | struct unary_function
```
Use the MACRO outlined in
https://github.com/boostorg/container_hash/issues/22, to prevent it's
use.
BOOST_NO_CXX98_FUNCTION_BASE:
> The standard library no longer supports std::unary_function and std::binary_function.
> They were deprecated in C++11 and is removed from C++14.
See:
https://github.com/boostorg/config/pull/430https://en.cppreference.com/w/cpp/utility/functional/unary_functionhttps://www.boost.org/doc/libs/master/libs/config/doc/html/boost_config/boost_macro_reference.html
58a9601dff build: globally define NOMINMAX (fanquake)
Pull request description:
Define (and document) `NOMINMAX` once, rather than across multiple
source files.
Defining this prevents the definition of min/max macros when using
mingw-w64, which may conflict with unprefixed std::min/max usage. While
that might not be the case for us, we'd always prefer to use the standard
library in any case.
For example:
73cadc06c6/mingw-w64-headers/include/ntdef.h (L289-L300)
Note that we already define NOMINMAX globally when building with MSVC.
Guix Build (arm64):
```bash
d3a3b7045dc1677f6a0a2a73a484f156c81ae764058003d9e870b346912b744a guix-build-58a9601dffa6/output/arm-linux-gnueabihf/SHA256SUMS.part
3e66540a3f8c8a10864ab2fed69581241fa41af86bbb028e5f7c3dd4ba859c64 guix-build-58a9601dffa6/output/arm-linux-gnueabihf/bitcoin-58a9601dffa6-arm-linux-gnueabihf-debug.tar.gz
78756e20d45e327cfd7f9e65858bf6d3814bcbe08f9f825fd6dfc9dff999ea6d guix-build-58a9601dffa6/output/arm-linux-gnueabihf/bitcoin-58a9601dffa6-arm-linux-gnueabihf.tar.gz
11073e88d4fd0411c5119a3dca3a90788693fa9aa5134339c84be98ae893cd77 guix-build-58a9601dffa6/output/arm64-apple-darwin/SHA256SUMS.part
deffd5f8c6286be34bc35e71ec70300bacb37e1b1a83e67c0833cb57d7a45529 guix-build-58a9601dffa6/output/arm64-apple-darwin/bitcoin-58a9601dffa6-arm64-apple-darwin-unsigned.dmg
acee7e98c5ec41f67e86c78dc5b45fa8bc82de86a04b8c43dbf9c59e7aff36a9 guix-build-58a9601dffa6/output/arm64-apple-darwin/bitcoin-58a9601dffa6-arm64-apple-darwin-unsigned.tar.gz
83f7cbaf6680fe8981db9260b97ca87d609a76c0857a744c7d406645d2484e1b guix-build-58a9601dffa6/output/arm64-apple-darwin/bitcoin-58a9601dffa6-arm64-apple-darwin.tar.gz
b8c73b40a5e307e9e7e482ce92164990d442f3f105a5240ec6eb96a775cb35d5 guix-build-58a9601dffa6/output/dist-archive/bitcoin-58a9601dffa6.tar.gz
cc435cd925771af7e261d0121047339ea8fddb0d1548b699c12108a62988cd32 guix-build-58a9601dffa6/output/powerpc64-linux-gnu/SHA256SUMS.part
7a68bd3181a054056b0a5eb6e830b90ac4ba8435114127d5f1720643011aa78f guix-build-58a9601dffa6/output/powerpc64-linux-gnu/bitcoin-58a9601dffa6-powerpc64-linux-gnu-debug.tar.gz
bc55b95e263c455a964d9463a3ee60dabee1d10cefc6641ed29a3b1b317d61e0 guix-build-58a9601dffa6/output/powerpc64-linux-gnu/bitcoin-58a9601dffa6-powerpc64-linux-gnu.tar.gz
49df78009d80af02262806c6c395e2c884a979b1ea13d01aa27d8188403e29d1 guix-build-58a9601dffa6/output/powerpc64le-linux-gnu/SHA256SUMS.part
29dc7a0e10707b3511fa2afb6977df7ebbb67f796d8be5a042abc14eba764aef guix-build-58a9601dffa6/output/powerpc64le-linux-gnu/bitcoin-58a9601dffa6-powerpc64le-linux-gnu-debug.tar.gz
51b7f8e1bccff1e2ce1860bbc382eefe648b90cc3374cdfa3a95a7454386e77d guix-build-58a9601dffa6/output/powerpc64le-linux-gnu/bitcoin-58a9601dffa6-powerpc64le-linux-gnu.tar.gz
e62e46d8cebbbfc0f587e930acb648fcae99cfe8b2f63aeba98e46e3338fe1e3 guix-build-58a9601dffa6/output/riscv64-linux-gnu/SHA256SUMS.part
fa5d0a074ca586583bf08dbf748909b3ff5e0a54a2e5aaa88abec666e17b4e72 guix-build-58a9601dffa6/output/riscv64-linux-gnu/bitcoin-58a9601dffa6-riscv64-linux-gnu-debug.tar.gz
684b2917fd27a41f884bb6870f7fac847d52b6f8b40df5779d1c674409f7cd14 guix-build-58a9601dffa6/output/riscv64-linux-gnu/bitcoin-58a9601dffa6-riscv64-linux-gnu.tar.gz
7d7cfd0212b49eec48c7f8dc0d97add53096685dfd646feac466c27a45d20c97 guix-build-58a9601dffa6/output/x86_64-apple-darwin/SHA256SUMS.part
d70ae6d060b7832f8741dc5d1958cc0d32702605c863254303107246deec0aa6 guix-build-58a9601dffa6/output/x86_64-apple-darwin/bitcoin-58a9601dffa6-x86_64-apple-darwin-unsigned.dmg
930f3ec43896404208ebdb582c9175e3a5a2470d778722e0001addde84dad99a guix-build-58a9601dffa6/output/x86_64-apple-darwin/bitcoin-58a9601dffa6-x86_64-apple-darwin-unsigned.tar.gz
2d8a9d12aadcf60634db953fcb8bd496a002608e9a64eb7d60bb7ffe1f94489f guix-build-58a9601dffa6/output/x86_64-apple-darwin/bitcoin-58a9601dffa6-x86_64-apple-darwin.tar.gz
10363729ece6e1c2cbdf435483006191bf17d1def2d318ff8357197d91c06ded guix-build-58a9601dffa6/output/x86_64-linux-gnu/SHA256SUMS.part
d50ec8e4f72e8b064b196eb0ece212f7b0b126f4b8b644c4451084cbf0416072 guix-build-58a9601dffa6/output/x86_64-linux-gnu/bitcoin-58a9601dffa6-x86_64-linux-gnu-debug.tar.gz
471e12b8715ecff4d99121c4bb3288ef4b005ca468810a714c67ea3e7c6669e9 guix-build-58a9601dffa6/output/x86_64-linux-gnu/bitcoin-58a9601dffa6-x86_64-linux-gnu.tar.gz
d63946401952d131fdf5df9442c52151d86e53f019234b5ad16fdef0d2976356 guix-build-58a9601dffa6/output/x86_64-w64-mingw32/SHA256SUMS.part
5359782e1eb6f449338f18e053ad82f25382d968690208ae5739d9338eb7bdc7 guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64-debug.zip
0d387d5a4cb1d712556a3fe5b4bd1e928bb5fbbe57a85ee06c746f132a6b1ec5 guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64-setup-unsigned.exe
dbfd7419d1d764e853a9dc041e276669b488aea4a80e21e4a175b6c3e512e70c guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64-unsigned.tar.gz
0ba07504d9d5a12af9144e8b386b2640b48dba067d47c694a44ecffe56b0c0fc guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK 58a9601dff
Tree-SHA512: d1c22b3d0d21ef8f9f605ef6ca06353e3f48536d84f3531f93d613a6ccbbe62f12fae0ed09e8b9a8940b0ef33f9d41d9991eb56fbe7c4ab48f0ce7fcf44e08b1
Define (and document) `NOMINMAX` once, rather than across multiple
source files.
Defining this prevents the definition of min/max macros when using
mingw-w64, which may conflict with unprefixed std::min/max usage. While
that might not be the case for us, we'd always prefer to use the standard
library in any case.
For example:
73cadc06c6/mingw-w64-headers/include/ntdef.h (L289-L300)
f0f5cd79b5 Bugfix: configure: Define default for use_libevent (Luke Dashjr)
Pull request description:
Another trivial fix like #25051 - I think this is the only other one missing.
ACKs for top commit:
laanwj:
Code review ACK f0f5cd79b5
Tree-SHA512: 888c2e6d032ef1de5af635e2a9b2b8ab560c86bd10a6cee54aa9aa62ae43f03c19889bb6a2b64cf8982d4cd514f97ca3ed743c71ed0651e9295a4b1726955b9b
Code introduced in #15649 added usage of `timingsafe_bcmp()`, if
available, otherwise falling back to our own implementation. However
the relevant build system check was never added, so currently, we'll
always just use our implementation, as HAVE_TIMINGSAFE_BCMP will never
be defined.
Add the check for timingsafe_bcmp. Note that as far as I'm aware, it's
only available on OpenBSD.
06e18e0b53 build: use BOOST_MULTI_INDEX_ENABLE_SAFE_MODE when debugging (fanquake)
Pull request description:
Use of this macro enables precondition checks for iterators and functions of the library. It's use is recommended in debug builds. See https://www.boost.org/doc/libs/1_78_0/libs/multi_index/doc/tutorial/debug.html for more info.
There is also a `BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING` macro:
> When this mode is in effect, all public functions of Boost.MultiIndex will perform post-execution tests aimed at ensuring that the basic internal invariants of the data structures managed are preserved.
ACKs for top commit:
laanwj:
Concept and code review ACK 06e18e0b53
Tree-SHA512: 7ee489eccda81c7dbca9210af6d3007d5b2c704b645139d2714c077af157789dd9478c29d0d212e210e96686ea83713aaf3d458e879122b3cde64f3e3e3789d2
7fd0860d12 Bugfix: configure: Define defaults for enable_arm_{crc,shani} (Luke Dashjr)
Pull request description:
Fix for #17398 and #24115
Trivial, mostly for consistency (you'd have to *try* to break this)
ACKs for top commit:
pk-b2:
ACK 7fd0860d12
seejee:
ACK 7fd0860d12
vincenzopalazzo:
ACK 7fd0860d12
Tree-SHA512: 51c389787c369f431ca57071f03392438bff9fd41f128c63ce74ca30d2257213f8be225efcb5c1329ad80b714f44427d721215d4f848cc8e63060fa5bc8f1f2e
165903406e build: Fix `AC_CHECK_HEADERS` and `AC_CHECK_LIB` for `libnatpmp` package (Hennadii Stepanov)
65cddf604c build: Fix `AC_CHECK_HEADERS` and `AC_CHECK_LIB` for `miniupnpc` package (Hennadii Stepanov)
bbbcb96638 build, refactor: Fix indentation (Hennadii Stepanov)
Pull request description:
Apparently, bitcoin/bitcoin#24391 broke the [ability](https://github.com/bitcoin/bitcoin/pull/22397) of the `configure` script to pick up Homebrew's `miniupnpc` and `libnatpmp` packages on macOS Apple M1.
This PR fixes it.
ACKs for top commit:
promag:
Tested ACK 165903406e
jarolrod:
tACK 165903406e
Tree-SHA512: 93988f59f425890d60582b93d4ac5b2ad03011a5c6dbb44678a3ca591da7518c1c741bc1045b2c763bbe887947f32293b38d55fd7a96f09d2092ad34baa1db21
035fa1f07a build: Remove LIBTOOL_APP_LDFLAGS for bitcoin-chainstate (Cory Fields)
3f0595095d docs: Add libbitcoinkernel_la_SOURCES explanation (Carl Dong)
94ad45deb2 ci: Build libbitcoinkernel (Carl Dong)
26b2e7ffb3 build: Extract the libbitcoinkernel library (Carl Dong)
1df44dd20c b-cs: Define G_TRANSLATION_FUN in bitcoinkernel.cpp (Carl Dong)
83a0bb7cc9 build: Separate lib_LTLIBRARIES initialization (Carl Dong)
c1e16cb31f build: Create .la library for bitcoincrypto (Carl Dong)
8bdfe057c7 build: Create .la library for leveldb (Carl Dong)
05d1525b6d build: Create .la library for crc32c (Carl Dong)
64caf94479 build: Remove vestigial LIBLEVELDB_SSE42 (Carl Dong)
1392e8e2d8 build: Don't add unrelated libs to LIBTEST_* (Carl Dong)
Pull request description:
Part of: #24303
This PR introduces a `libbitcoinkernel` static library linking in the minimal list of files necessary to use our consensus engine as-is. `bitcoin-chainstate` introduced in #24304 now will link against `libbitcoinkernel`.
Most of the changes are related to the build system.
Please read the commit messages for more details.
ACKs for top commit:
theuni:
This may be my favorite PR ever. It's a privilege to ACK 035fa1f07a.
Tree-SHA512: b755edc3471c7c1098847e9b16ab182a6abb7582563d9da516de376a770ac7543c6fdb24238ddd4d3d2d458f905a0c0614b8667aab182aa7e6b80c1cca7090bc
9b0a13a289 tidy: Add include-what-you-use (fanquake)
74cd038e30 refactor: fix includes in src/init (fanquake)
c79ad935f0 refactor: fix includes in src/compat (fanquake)
Pull request description:
We recently added a [`clang-tidy` job](https://github.com/bitcoin/bitcoin/blob/master/ci/test/00_setup_env_native_tidy.sh) to the CI, which generates a compilation database. We can leverage that now existing database to begin running [include-what-you-use](https://include-what-you-use.org/) over the codebase.
This PR demonstrates using a mapping_file to indicate fixups / includes that may differ from IWYU suggestions. In this case, I've added some fixups for glibc includes that I've [upstreamed changes for](https://github.com/include-what-you-use/include-what-you-use/pull/1026):
```bash
# Fixups / upstreamed changes
[
{ include: [ "<bits/termios-c_lflag.h>", private, "<termios.h>", public ] },
{ include: [ "<bits/termios-struct.h>", private, "<termios.h>", public ] },
{ include: [ "<bits/termios-tcflow.h>", private, "<termios.h>", public ] },
]
```
The include "fixing" commits of this PR:
* Adds missing includes.
* Swaps C headers for their C++ counterparts.
* Removes the pointless / unmaintainable `//for abc, xyz` comments. When using IWYU, if anyone wants to see / generate those comments, to see why something is included, it is trivial to do so (IWYU outputs them by default). i.e:
```cpp
// The full include-list for compat/stdin.cpp:
#include <compat/stdin.h>
#include <poll.h> // for poll, pollfd, POLLIN
#include <termios.h> // for tcgetattr, tcsetattr
#include <unistd.h> // for isatty, STDIN_FILENO
```
TODO:
- [ ] Qt mapping_file. There is one in the IWYU repo, but it's for Qt 5.11. Needs testing.
- [ ] Boost mapping_file. There is one in the IWYU repo, but it's for Boost 1.75. Needs testing.
I'm not suggesting we turn this on the for entire codebase, or immediately go-nuts refactoring all includes. However I think our dependency includes are now slim enough, and our CI infrastructure in place such that we can start doing this in some capacity, and just automate away include fixups / refactorings etc.
ACKs for top commit:
MarcoFalke:
review ACK 9b0a13a289
jonatack:
ACK 9b0a13a289 reviewed changes and run CI output in https://cirrus-ci.com/task/4750910332076032
Tree-SHA512: 00beab5a5f2a6fc179abf08321a15391ecccaa91ab56f3c50c511e7b29a0d7c95d8bb43eac2c31489711086f6f77319d43d803cf8ea458e7cd234a780d9ae69e
I strongly recommend reviewing with the following git-diff flags:
--patience --color-moved=dimmed-zebra
Extract out a libbitcoinkernel library linking in all files necessary
for using our consensus engine as-is. Link bitcoin-chainstate against
it.
See previous commit "build: Add example bitcoin-chainstate executable"
for more context.
We explicitly specify -fvisibility=default, which effectively overrides
the effects of --enable-reduced-exports since libbitcoinkernel requires
default symbol visibility
When compiling for mingw-w64, specify -static in both:
- ..._la_CXXFLAGS so that libtool will avoid building two versions of
each object (one PIC, one non-PIC). We just need the one that is
suitable for static linking.
- ..._la_LDFLAGS so that libtool will create a static library.
If we don't specify this, then libtool will prefer the non-static PIC
version of the object, which is built with -DDLL_EXPORT -DPIC for
mingw-w64 targets. This can cause symbol resolution problems when we
link this library against an executable that does specify -all-static,
since that will be built without the -DDLL_EXPORT flag.
Unfortunately, this means that for mingw-w64 we can only build a static
version of the library for now. This will be fixed.
However, on other targets, the shared library creation works fine.
-----
Note to users: You need to either specify:
--enable-experimental-util-chainstate
or,
--with-experimental-kernel-lib
To build the libbitcionkernel library. See the configure help for more
details.
build shared libbitcoinkernel where we can
This change makes naming of `install_name_tool` consistent across
the whole build system.
-BEGIN VERIFY SCRIPT-
sed --in-place --expression='s/INSTALLNAMETOOL/INSTALL_NAME_TOOL/g' $(git grep --files-with-matches 'INSTALLNAMETOOL')
-END VERIFY SCRIPT-
1dd8cbfbc6 build: don't compress macOS DMG (fanquake)
Pull request description:
Skip compressing the macOS DMG, and drop related build steps and dependencies. Uncompressed the DMG increases from ~16mb to ~30mb, which compared to other software a user may download, (Firefox 125mb, VLC 52mb, Open Office 176mb), is still relatively small. When contrasted against the 100's of GB of blockchain data a node will download, an additional 15mb to get the release binary, isn't much additional overhead. Note that if / when we build with LTO enabled for releases, this size will shrink back down significantly again.
`native_libdmg-hfsplus` is not maintained, and I doubt the DMG creation feature will ever be fixed. If at some point `xorrisofs` supports compressing dmgs, we could enable that.
Guix Build on x86_64:
```bash
25b7c8bb7bc8ea014d43cebb844a842d2ac8d5a343039a820d24b649c9e6bc8a guix-build-1dd8cbfbc631/output/arm64-apple-darwin/SHA256SUMS.part
16beb5c52c9bf51b5ce9ef5a0d17c0038238a833383586a1b14acbca78533e4b guix-build-1dd8cbfbc631/output/arm64-apple-darwin/bitcoin-1dd8cbfbc631-arm64-apple-darwin-unsigned.dmg
d8f89a61a7448d6334dbb3639386a7b6340542393933f35421a9e6dfc724e455 guix-build-1dd8cbfbc631/output/arm64-apple-darwin/bitcoin-1dd8cbfbc631-arm64-apple-darwin-unsigned.tar.gz
11617dc261ef602433f5bb29956a40a9085dbc783f519f75fbe06e80970148d0 guix-build-1dd8cbfbc631/output/arm64-apple-darwin/bitcoin-1dd8cbfbc631-arm64-apple-darwin.tar.gz
aa8550d4a394d3161d14ec5e6012ed07354135afb022e905a1946785b4665664 guix-build-1dd8cbfbc631/output/dist-archive/bitcoin-1dd8cbfbc631.tar.gz
2b837f2f971a9738d0b7b8497f7ded740ef5e67c8baa7f30ca33e6b7d826eec8 guix-build-1dd8cbfbc631/output/x86_64-apple-darwin/SHA256SUMS.part
db972b2c06dbde5525a3f9e6ceb9c20a8120bc9a6f15e1d852a4bfac09d88569 guix-build-1dd8cbfbc631/output/x86_64-apple-darwin/bitcoin-1dd8cbfbc631-x86_64-apple-darwin-unsigned.dmg
50fe990c3f9923ee92195125faf6517396e7c1b017a8f4f7d52e991ebce52f0c guix-build-1dd8cbfbc631/output/x86_64-apple-darwin/bitcoin-1dd8cbfbc631-x86_64-apple-darwin-unsigned.tar.gz
1d9022b0ae46ead41046c40f82291ce363760660a3cd6e6ef6a5b1128b90faef guix-build-1dd8cbfbc631/output/x86_64-apple-darwin/bitcoin-1dd8cbfbc631-x86_64-apple-darwin.tar.gz
```
Guix Build on arm64:
```bash
```
ACKs for top commit:
Sjors:
re-tACK 1dd8cbfbc6 on Intel macOS
laanwj:
Build system changes code review ACK 1dd8cbfbc6, I don't know anything about MacOS application formats and their internals so do not have an opinion on the contents of this change.
jarolrod:
ACK 1dd8cbfbc6
Tree-SHA512: 04c5bf78f26a9877777093ec4c50c457107bef59d720839ea5e7d7e4f7961dfee9f86b40cf791524a9e60e9e77403a797e9fcdae3849b60b759f9f66cc31b6ab
c9c4e6cadd build: Do not define `PROVIDE_FUZZ_MAIN_FUNCTION` macro unconditionally (Hennadii Stepanov)
Pull request description:
No need to define the `PROVIDE_FUZZ_MAIN_FUNCTION` macro when the build system has been configured with the `--disable-fuzz-binary` option.
See https://github.com/bitcoin/bitcoin/pull/24336#pullrequestreview-881368272.
ACKs for top commit:
MarcoFalke:
Approach ACK c9c4e6cadd did not review or test 🐤
fanquake:
ACK c9c4e6cadd Checked that `PROVIDE_FUZZ_MAIN_FUNCTION` isn't defined when configuring with `--disable-fuzz-binary`.
Tree-SHA512: 54fbf02ba9f5ecc61b176b8ea7d05e308788d4de3f97ed40913e731300d9dc0edfdfcbf8e0a6e74cf1b2e2ae63f6208a34e03b9c8d203d070c457c4a7d9b5f2c
404c53062b key: use secp256k1_schnorrsig_sign32 over deprecated secp256k1_schnorrsig_sign (fanquake)
ee30bf7c01 build: remove some no-longer-needed var unexporting from configure (fanquake)
2656629767 build: remove --enable-experimental from libsecp256k1 configure (fanquake)
d960d4fd3a build: fix MSVC build after subtree update (dhruv)
afb7a6fe06 Squashed 'src/secp256k1/' changes from 0559fc6e41..8746600eec (fanquake)
Pull request description:
The motivation for this bump is some small build cleanups, including [dropping the `--enable-experimental`](80cf4eea5f) flag from the libsecp configure invocation, as well as some [now-redundant](https://github.com/bitcoin-core/secp256k1/pull/1090) `pkg-config` variable exporting from our own configure. We also get the benefit of a slightly more efficient libsecp configure due to https://github.com/bitcoin-core/secp256k1/pull/1088.
This also includes a change in our code to migrate from using the [now deprecated](99e6568fc6) `secp256k1_schnorrsig_sign` to `secp256k1_schnorrsig_sign32`.
Guix Build (on x86_64):
```bash
b9f6ad90c75f7edd7c4444c6c3401d8b6ab29a8da22ae22ddaedd94688227b5d guix-build-404c53062bb8/output/aarch64-linux-gnu/SHA256SUMS.part
250d47ae299d8385d5590518fa2adaabde76e2566fd27e12bf36b62663d13e13 guix-build-404c53062bb8/output/aarch64-linux-gnu/bitcoin-404c53062bb8-aarch64-linux-gnu-debug.tar.gz
48d610dc6f5169f925f782571dac2f082695f89008beadad4adef4c1b583a612 guix-build-404c53062bb8/output/aarch64-linux-gnu/bitcoin-404c53062bb8-aarch64-linux-gnu.tar.gz
8f04ee26e4079719e3935bd0e4287cc11a2a16875bf01e2a63d67492a1fa5367 guix-build-404c53062bb8/output/arm-linux-gnueabihf/SHA256SUMS.part
7d7d7fcfb032bda92e53abd8d608257f0ef17b1e3e52a1414260b896786fb2dc guix-build-404c53062bb8/output/arm-linux-gnueabihf/bitcoin-404c53062bb8-arm-linux-gnueabihf-debug.tar.gz
30bae2ff3d044f4e39f992a68f6b296b7be2aea350bca4a0415c739a32c20bd9 guix-build-404c53062bb8/output/arm-linux-gnueabihf/bitcoin-404c53062bb8-arm-linux-gnueabihf.tar.gz
5f550fb0b950250eeffce3480ec6403530b0880570a5860ef6c32a3e92eac92f guix-build-404c53062bb8/output/arm64-apple-darwin/SHA256SUMS.part
c10664d13aeec8c860bf72be833c738973ae18e4d28cdf08b2f9bee960ebff1d guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin-unsigned.dmg
becab75b11cf4ca6f559f8eef835f3574629f6eb932ac716ed4f8c044a85831f guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin-unsigned.tar.gz
bc86433652fe3552f6a13088191364ae7514c9fe3a244da86a6db096bb4922fc guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin.tar.gz
1f585cb9a1356343df4b2726ecfe2598c9903304afb047c047c2cef318555dd3 guix-build-404c53062bb8/output/dist-archive/bitcoin-404c53062bb8.tar.gz
9ede534ba2c6cecb550473eead195627327e826ebb0118e23d60ab482d40e241 guix-build-404c53062bb8/output/powerpc64-linux-gnu/SHA256SUMS.part
77ddb7d7d639b1dd4508468a8ef27e45b35c8b2f8624584a70e6b64798a4ea7a guix-build-404c53062bb8/output/powerpc64-linux-gnu/bitcoin-404c53062bb8-powerpc64-linux-gnu-debug.tar.gz
36178c1f1c12942ff05275daa3570f8b45419ee8d9f391d750afb405219986f0 guix-build-404c53062bb8/output/powerpc64-linux-gnu/bitcoin-404c53062bb8-powerpc64-linux-gnu.tar.gz
8a15a4da7a9a5e00c49d9aeedf3c6fc666c0d230be1369eac7caf4571d5905e0 guix-build-404c53062bb8/output/powerpc64le-linux-gnu/SHA256SUMS.part
400c58113f2d07c87e03c8528b292c6aca808a2bccae4b041cad3a26a05b6aad guix-build-404c53062bb8/output/powerpc64le-linux-gnu/bitcoin-404c53062bb8-powerpc64le-linux-gnu-debug.tar.gz
3b9f9d8614ac3a27416e53354b2b0a64d364f91493e9d0f41583a6f492546824 guix-build-404c53062bb8/output/powerpc64le-linux-gnu/bitcoin-404c53062bb8-powerpc64le-linux-gnu.tar.gz
98506b23ee08ad8af958f816da2e4518d661e88d5c6308de1f5e3b2fc787b86c guix-build-404c53062bb8/output/riscv64-linux-gnu/SHA256SUMS.part
c701a7b77cea4fdc2588b511f1b2c71b89c83bfba19fdb2ac113a5a4b14ac392 guix-build-404c53062bb8/output/riscv64-linux-gnu/bitcoin-404c53062bb8-riscv64-linux-gnu-debug.tar.gz
34d58e6392cd58b3c76e30cd8600c0dbefba7e9c6d5df78c3ef23e81c4e4d26a guix-build-404c53062bb8/output/riscv64-linux-gnu/bitcoin-404c53062bb8-riscv64-linux-gnu.tar.gz
92fa30e9c6d81dd1e1514b65d3e1abe68ded897237cd99f66aa760d445109c04 guix-build-404c53062bb8/output/x86_64-apple-darwin/SHA256SUMS.part
bee180b02f178ae9980ef159f65913a71cbd037c4aff5f2906af5f174a677da3 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin-unsigned.dmg
ad7d18d779ab7a7944817d1f368d0a6bdd174bf1211b0f90180c8ccf04ec4062 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin-unsigned.tar.gz
7489d1d5d48ad95cf58bb11b5fdeccadac6fa758784fb498529fca2330abe069 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin.tar.gz
74660fb0ebce2a08b03980a57bffcad62e078dc967a74d2395660ff51c019640 guix-build-404c53062bb8/output/x86_64-linux-gnu/SHA256SUMS.part
cd377fa6b46276c2f8a32e199e6f9adf6aa67315688656709d6dc0744d54a837 guix-build-404c53062bb8/output/x86_64-linux-gnu/bitcoin-404c53062bb8-x86_64-linux-gnu-debug.tar.gz
919c521950369d8ad46db2d15b00abb488abfb080d157a41b2db429122a428ed guix-build-404c53062bb8/output/x86_64-linux-gnu/bitcoin-404c53062bb8-x86_64-linux-gnu.tar.gz
2debca995d432965a8786b6ff74aed42e9e2f1cb0fecbe2d9fc5b850c192fcff guix-build-404c53062bb8/output/x86_64-w64-mingw32/SHA256SUMS.part
e33169f684fb031ec18ed39812617d3eb263257f6c7564b8f4c974ad05fe672c guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-debug.zip
029d0a4180cb908d517fcf689dcf46d42fbf383e11dc609711617066ae039ab0 guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-setup-unsigned.exe
7e349c688cac66436562c4805f420b0536db5a3b3abf54d0e8c7752f59874a5c guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-unsigned.tar.gz
1bff98e82e95c93d6060227408502f5e2d8597d526b912cb6dc0a90ae3094a8f guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK 404c53062b, I checked the changes to our tree thoroughly but didn't review all upstream secp256k1 changes in detail.
gruve-p:
ACK 404c53062b
real-or-random:
utACK 404c53062b I reviewed the diff to Core, I'm with updating to libsecp256k1 master, but I haven't verified that the libsecp256k1 tree here has been updated correctly
Tree-SHA512: e6a6db93ea60ed500df5065178784a915da94adfa7bd45fdbd7b19d701154987ff38c1df7f318119e6c2cb98e28e1ea2eb725bef93d4088403e14537ebffb032
76c60d7b31 test: validation:block_connected tracepoint test (0xb10c)
260e28ece8 test: utxocache:* tracepoint tests (0xb10c)
34b27bac68 test: net:in/out_message tracepoint tests (0xb10c)
c934087b62 test: checks for tracepoint tests (0xb10c)
Pull request description:
This adds functional tests for the USDT tracepoints added in https://github.com/bitcoin/bitcoin/pull/22006 and https://github.com/bitcoin/bitcoin/pull/22902. This partially fixes#23296. The tests **are probably skipped** on most systems as these tests require:
- a Linux system with a kernel that supports BPF (and available kernel headers)
- that Bitcoin Core is compiled with tracepoints for USDT support (default when compiled with depends)
- [bcc](https://github.com/iovisor/bcc) installed
- the tests are run with a privileged user that is able to e.g. do BPF syscalls and load BPF maps
The tests are not yet run in our CI as the CirrusCI containers lack the required permissions (see https://github.com/bitcoin/bitcoin/issues/23296#issuecomment-1024920845). Running the tests in a VM in the CI could work, but I haven't experimented with this yet. The priority was to get the actual tests done first to ensure the tracepoints work as intended for the v23.0 release. Running the tracepoint tests in the CI is planned as the next step to finish #23296.
The tests can, however, be run against e.g. release candidates by hand. Additionally, they provide a starting point for tests for future tracepoints. PRs adding new tracepoint should include tests. This makes reviewing these PRs easier.
The tests require privileges to execute BPF sycalls (`CAP_SYS_ADMIN` before Linux kernel 5.8 and `CAP_BPF` and `CAP_PERFMON` on 5.8+) and permissions to `/sys/kernel/debug/tracing/`. It's currently recommended to run the tests in a virtual machine (or on a VPS) where it's sensible to use the `root` user to gain these privileges. Never run python scripts you haven't carefully reviewed with `root` permissions! It's unclear if a non-root user can even gain the required privileges. This needs more experimenting.
The goal here is to test the tracepoint interface to make sure the [documented interface](https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md#tracepoint-documentation) does not break by accident. The tracepoints expose implementation details. This means we also need to rely on implementation details of Bitcoin Core in these functional tests to trigger the tracepoints. An example is the test of the `utxocache:flush` tracepoint: On Bitcoin Core shutdown, the UTXO cache is flushed twice. The corresponding tracepoint test expects two flushes, too - if not, the test fails. Changing implementation details could cause these tests to fail and the tracepoint API to break. However, we purposefully treat the tracepoints only as [**semi-stable**](https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md#semi-stable-api). The tracepoints should not block refactors or changes to other internals.
ACKs for top commit:
jb55:
tACK 76c60d7b31
laanwj:
Tested ACK 76c60d7b31
Tree-SHA512: 9a63d945c68102e59d751bd8d2805ddd7b37185408fa831d28a9cb6641b701961389b55f216c475df7d4771154e735625067ee957fc74f454ad7a7921255364c
7b00595d33 build: stop overriding user CXXFLAGS (fanquake)
3e2ef23c3e build: stop overriding user LDFLAGS (fanquake)
35c3fd43c3 build: stop overriding user CPPFLAGS (fanquake)
bc7cc57607 doc: explain why we clear CXXFLAGS with enable-debug (fanquake)
Pull request description:
Historically our build system has hijacked `CXXFLAGS` and friends, and this has always been a source of complaints from users and developers. With this PR, we move away from using `CXXFLAGS`, `CPPFLAGS` and `LDFLAGS`, and instead use `CORE_*FLAGS` variables for our flags / options, leaving autoconfs `FLAG` vars to the user.
Note that there are currently two cases where we will at least clear `CXXFLAGS` (if not alreaddy overridden by the user), when doing debugging or when coverage is enabled, to avoid Autoconfs `-g -O2` CXXFLAG default.
ACKs for top commit:
hebasto:
ACK 7b00595d33
Tree-SHA512: bda936a7aa8f98a1bf1552306845cb4bbab54e19a7a0b9ce3210e10fef70db146e9fe42a0cc8c50b2908506771b5b96f39c334e41323b70ec878e4010373096c
0d01272cd8 build: don't use Boost multi_index serialization (fanquake)
Pull request description:
We don't use the serialization or archiving facilities of multi_index.
So globally disable support, which gives a minor improvement in build
time, i.e less preprocessing work, given we don't link any Boost libs.
See: https://www.boost.org/doc/libs/1_78_0/libs/multi_index/doc/tutorial/creation.html
> Serialization capabilities are automatically provided by just linking with the appropriate Boost.Serialization library module: it is not necessary to explicitly include any header from Boost.Serialization, apart from those declaring the type of archive used in the process. If not used, however, serialization support can be disabled by globally defining the macro BOOST_MULTI_INDEX_DISABLE_SERIALIZATION. Disabling serialization for Boost.MultiIndex can yield a small improvement in build times, and may be necessary in those defective compilers that fail to correctly process Boost.Serialization headers.
ACKs for top commit:
MarcoFalke:
cr ACK 0d01272cd8
Tree-SHA512: 87c664a2f142dc6b8f8598341f9829be3fda8cf614d73cc9a894c8033ee40c6daa9b50f4049ecb1f1e3aaf342568d9a5f5c65af1e04c36ee3a9cb46eca95767b
d4ba2b2cbc compat: remove strnlen back-compat code (fanquake)
Pull request description:
This was needed for mingw (not mingw-w64), and some older versions of
macOS, which we no-longer support.
ACKs for top commit:
hebasto:
ACK d4ba2b2cbc
Tree-SHA512: d1beb9df58464feea3076091361d7d46e4a8901e347644a5fa6f24e052ca24ee0c7c0dd3f2a3d682b0204bf50430fa89eac62121691ea08af6dcf6b907bdec87
532c64a726 build: Fix Boost.Process test for Boost 1.78 (Hennadii Stepanov)
Pull request description:
Rebased #24415 with Luke's suggestion.
Fixes#24413.
ACKs for top commit:
hebasto:
ACK 532c64a726, tested on Mac mini (M1, 2020) + macOS Monterey 12.3 (21E230).
Tree-SHA512: 74f779695f6bbc45a2b7341a1402f747cc0d433d74825c7196cb9f156db0c0299895365f01665bd0bff12a8ebb5ea33a29b9a52f5eac0007ec35d1dca6544705
5a157eb370 Bugfix: configure: Only avoid -isystem for exact /usr/include path (Luke Dashjr)
556ee6f2fa Bugfix: configure: Quote SUPPRESS_WARNINGS sufficiently to preserve brackets (Luke Dashjr)
Pull request description:
The regex includes `[/ ]` which is supposed to match either a forward slash or a space, but m4 treats the brackets as special characters and effectively strips them out, leading to -isystem /usr/include paths except for in the typical scenario where it is the final parameter in the flag string.
ACKs for top commit:
hebasto:
ACK 5a157eb370, tested on Ubuntu 22.04 with clang 14.0.
vasild:
ACK 5a157eb370
Tree-SHA512: 5c8c282b647b7853b8fad1b5b473703c4a0635073d2685a8ac984151046e2c6a859e6972465419d27356dd29a47f21a2a3a6ad402ec434fe1f9882e5a35f0749
999982b06c build: Add --enable-c++20 option (MarcoFalke)
fae679065e Add CSerializedNetMsg::Copy() helper (MarcoFalke)
fabb7c4ba6 Make fs.h C++20 compliant (MarcoFalke)
fae2220f4e scheduler: Capture ‘this’ explicitly in lambda (MarcoFalke)
Pull request description:
This is for CI and devs only and doesn't change that C++17 is the standard we are currently using. The option `--enable-c++20` allows CI to check that the C++17 code in the repo is also valid C++20. (There are some cases where valid C++17 doesn't compile under C++20).
Also, it allows developers to easily play with C++20 in the codebase.
ACKs for top commit:
ryanofsky:
Code review ACK 999982b06c. Since last review was rebased, and enum-conversion change was dropped, and CSerializedNetMsg copy workaround was added
fanquake:
utACK 999982b06c
Tree-SHA512: afc95ba03ea2b937017fc8e2b1449379cd2b6f7093c430d2e344c665a00c51e402d6651cbcbd0be8118ea1e54c3a86e67d2021d19ba1d4da67168e9fcb6b6f83
