228d6a2969 build: Fix regression in "ARMv8 CRC32 intrinsics" test (Hennadii Stepanov)
Pull request description:
In the master branch, the `aarch64` binaries lack support for CRC32 intrinsics.
The `vmull_p64` is a part of the Crypto extensions from the ACLE. They are optional extensions, so they get enabled with a `+crypto` for architecture flags.
The regression was introduced in https://github.com/bitcoin/bitcoin/pull/26183 (v25.0).
The `./configure` script log excerpts:
- the master branch @ d752349029:
```
checking whether C++ compiler accepts -march=armv8-a+crc... yes
checking whether C++ compiler accepts -march=armv8-a+crypto... yes
checking for ARMv8 CRC32 intrinsics... no
checking for ARMv8 SHA-NI intrinsics... yes
```
- this PR:
```
checking whether C++ compiler accepts -march=armv8-a+crc+crypto... yes
checking whether C++ compiler accepts -march=armv8-a+crypto... yes
checking for ARMv8 CRC32 intrinsics... yes
checking for ARMv8 SHA-NI intrinsics... yes
```
Guix build:
```
x86_64
2afd81f540c6d3b36ff305e88bafe935e4272cd3efef3130aa69d49a0522541b guix-build-228d6a2969e4/output/aarch64-linux-gnu/SHA256SUMS.part
6c704d6d30d495adb3fb86befdb500eb389a02c1167163f14ab5c3c3e630e6b3 guix-build-228d6a2969e4/output/aarch64-linux-gnu/bitcoin-228d6a2969e4-aarch64-linux-gnu-debug.tar.gz
e4419963c9c0d99adc4e38538900b648f2c14f793b60c8ee2e6f5acc9d3fadd3 guix-build-228d6a2969e4/output/aarch64-linux-gnu/bitcoin-228d6a2969e4-aarch64-linux-gnu.tar.gz
7d11052b6bd28cdf26d5f2a4987f02d32c93a061907bcd048fb6d161a0466ca9 guix-build-228d6a2969e4/output/dist-archive/bitcoin-228d6a2969e4.tar.gz
```
ACKs for top commit:
TheCharlatan:
ACK 228d6a2969
Tree-SHA512: 4c27ca8acb953bf56e972d907a282ee19e3f30f7a4bf8a9822395fe0e28977cd6233e8b65b4a25cc1d3d5ff6a796d7af07653e18531c44ee3efaff1563d96d32
f95af98128 guix: default ssp for Windows GCC (fanquake)
95d55b96c2 guix: remove ssp workaround from Windows GCC (fanquake)
8f43302a0a build: remove explicit libssp linking from Windows build (fanquake)
Pull request description:
I was expecting this to fail to compile somewhere, maybe in the CI, but that doesn't seem to be the case?
Seems workable given the SSP related changes in the newer mingw-w64 headers (which are in Guix):
> Implement some of the stack protector functions/variables so -lssp is now optional when _FORTIFY_SOURCE or -fstack-protector-strong is used.
However I think this would still be broken in some older environments, so we might have to wait for a compiler bump, or similar. The optional -lssp also seems to work when using older headers, which doesn't make sense.
Would fix#28104.
ACKs for top commit:
hebasto:
ACK f95af98128, I've verified binaries from `bitcoin-f95af98128f1-win64.zip` on Windows 11 Pro 23H2.
TheCharlatan:
ACK f95af98128
Tree-SHA512: 71169ec513cfe692dfa7741d2bf37b45da05627c0af1cbd50cf8c3c04cc21c4bf88f3284532bddc1e3e648391ec78dbaca5170987a13c21ac204a7bcaf27f349
The `vmull_p64` is a part of the Crypto extensions from the ACLE. They
are optional extensions, so they get enabled with a `+crypto` for
architecture flags.
This is deprecated on macOS:
```bash
ld: warning: -bind_at_load is deprecated on macOS
```
and likely redundant anyways, given the behaviour of dyld3.
Unfortunately libtool is still injecting a `-bind_at_load`:
```bash
# Don't allow lazy linking, it breaks C++ global constructors
# But is supposedly fixed on 10.4 or later (yay!).
if test CXX = "$tagname"; then
case ${MACOSX_DEPLOYMENT_TARGET-10.0} in
10.[0123])
func_append compile_command " $wl-bind_at_load"
func_append finalize_command " $wl-bind_at_load"
;;
esac
fi
```
so this doesn't remove all the warnings, but removes us as a potential
source of them.
Note that anywhere the ld64 warnings are being emitted, we are already
not adding this flag to our hardened ldflags, because of `-Wl,-fatal_warnings`.
Having the link check in the header check loop means we get `-lminiupnpc
-lminiupnpc -lminiupnpc` on the link line. This is unnecessary, and
results in warnings, i.e:
```bash
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc'
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc'
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc'
```
These warnings have been occurring since the new linker released with
Xcode 15, and also came up in https://github.com/hebasto/bitcoin/pull/34.
fa25e8b0a1 doc: Recommend lint image build on every call (MarcoFalke)
faf70c1f33 Bump python minimum version to 3.9 (MarcoFalke)
fa8996b930 ci: Bump i686_multiprocess.sh to latest Ubuntu LTS (MarcoFalke)
Pull request description:
All supported operating systems ship with python 3.9 (or later), so bumping the minimum should not cause any issues. A bump will allow new code to use new python 3.9 features.
For reference:
* https://packages.debian.org/bullseye/python3
* https://packages.ubuntu.com/focal/python3.9
* FreeBSD 12/13 also ships with 3.9
* CentOS-like 8/9 also ships with 3.9 (and 3.11)
* OpenSuse Leap also ships with 3.9 (and 3.11) https://software.opensuse.org/package/python311-base
This is for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month.
ACKs for top commit:
Sjors:
ACK fa25e8b0a1
jamesob:
ACK fa25e8b0a1 ([`jamesob/ackr/28211.1.MarcoFalke.bump_python_minimum_supp`](https://github.com/jamesob/bitcoin/tree/ackr/28211.1.MarcoFalke.bump_python_minimum_supp))
Tree-SHA512: 86c9f6ac4b5ba94a62ee6a6062dd48a8295d8611a39cdb5829f4f0dbc77aaa1a51edccc7a99275bf699143ad3a6fe826de426d413e5a465e3b0e82b86d10c32e
This is not a hardening specific flag, it should be used at all times,
regardless of if hardening is enabled or not. Note that this was
still the case here, but having this exist in the hardening flags is
confusing, and may lead someone to move it inside one of the `use_hardening`
blocks, where it would become unused, with `--disable-hardening`.
This is a simpler (less hardening) version of #24123.
Scoped to aarch64 to avoid unused command line option warnings when
building on x86_64.
Related to #19075.
We currently work around a longstanding GCC issue with aligned vector
instructions, in our release builds, by patching the behaviour we want
into GCC (see discussion in #24736).
A new option now exists in the binutils assembler,
`-muse-unaligned-vector-move`, which should also achieve the behaviour
we want (at least for our code). This was added in the 2.38 release,
see
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c8480b58e1968f209b6365af7422678f348222c2.
```bash
x86: Add -muse-unaligned-vector-move to assembler
Unaligned load/store instructions on aligned memory or register are as
fast as aligned load/store instructions on modern Intel processors. Add
a command-line option, -muse-unaligned-vector-move, to x86 assembler to
encode encode aligned vector load/store instructions as unaligned
vector load/store instructions.
```
Even if we introduce this option into our build system, we'll have to
maintain our GCC patching, as we want all code that ends up in the
binary, to avoid these instructions. However, there may be some value in
adding the option, as it could be an improvement for someone building
(bitcoind.exe) with an unpatched compiler.
08eb5f1b67 ci: document that -Wreturn-type has been fixed upstream (Windows) (fanquake)
Pull request description:
`noreturn` attributes have been added to the mingw-w64 headers, 1690994f51, meaning that [from 11.0.0 onwards](https://www.mingw-w64.org/changelog/), you'll no-longer see `-Wreturn-type` warnings when using `assert(false)`.
Add -Wno-return-type to the Windows CI, where is should have been all
along, and document why it's required. This can be dropped when we are
using the fixed version of the mingw-w64 headers there.
Drop the -Werror -Wno-return-type special case from our build system.
-Wreturn-type is on by default in Clang and GCC.
The new mingw-w64 header behaviour can be checked on Ubuntu mantic, [which ships with 11.0.0](https://packages.ubuntu.com/mantic/mingw-w64), using:
```cpp
#include <cassert>
int f(){ assert(false); }
int main() {
return 0;
}
```
On Mantic (with 11.0.0):
```bash
x86_64-w64-mingw32-g++ test.cpp -Wreturn-type
# nada
```
On Lunar ([with 10.0.0](https://packages.ubuntu.com/lunar/mingw-w64)):
```bash
x86_64-w64-mingw32-g++ test.cpp -Wreturn-type
test.cpp: In function 'int f()':
test.cpp:3:25: warning: no return statement in function returning non-void [-Wreturn-type]
3 | int f(){ assert(false); }
| ^
```
ACKs for top commit:
TheCharlatan:
ACK 08eb5f1b67
Tree-SHA512: 9cd4310a96abd87bf8ceb37949ad0259fe4adee3367c604f4c4ad521a0cf09bdcc5dd305db19a0f45ce74c85178b0d739e2fca5ad0fc841ac935523a23b28a7f
`noreturn` attributes have been added to the mingw-w64 headers, meaning
that from 11.0.0 onwards, you'll no-longer see `-Wreturn-type` warnings
when using assert(false):
1690994f51.
Add -Wno-return-type to the Windows CI, where is should have been all
along, and document why it's required. This can be dropped when we are
using the fixed version of the mingw-w64 headers there.
Drop the -Werror -Wno-return-type special case from our build system.
-Wreturn-type is on by default in Clang and GCC.
8f6f0d81ee guix: backport glibc patch to prevent redundant librt link (fanquake)
e14473299c contrib: remove librt from release deps (fanquake)
e64e17830a build: remove check for gettimeofday & librt (fanquake)
Pull request description:
Our release binaries currently have a runtime dependency on `librt`. However this is redundant, and only the case due to a bug in glibc. The `clock_*` suit of funcs were absorbed into libc long ago, however an issue with compatibility code meant that librt would still be linked against / used redundantly:
> But the forwarders were not marked as compatibility symbols.
> As a result, on older architectures, historic configure checks such as
> AC_CHECK_LIB(rt, clock_gettime)
> still cause linking against librt, even though this is completely
> unnecessary. It also creates a needless porting hazard because
> architectures behave differently when it comes to symbol availability.
This PR drops our configure check for librt (which is redundant, and could be PR'd standalone), and backports [the relevant patch](https://sourceware.org/git/?p=glibc.git;a=commit;h=f289e656ec8221756519a601042bc9fbe1b310fb) into our glibc, so we can drop librt from our runtime dependencies.
Guix Build:
```bash
67078bddd5dc32801b8c916c3bc12f1404da572312f0158a89b9603c1f753969 guix-build-8f6f0d81ee3a/output/aarch64-linux-gnu/SHA256SUMS.part
794dd00009860fd67d7e51463ee1c5ea9677dfff1c739dd0b91cf73136deb655 guix-build-8f6f0d81ee3a/output/aarch64-linux-gnu/bitcoin-8f6f0d81ee3a-aarch64-linux-gnu-debug.tar.gz
eb9cf3f472ffbc37446fe4d80fe81dc62cf1c28c4d57dd8a7b7176e65487aeeb guix-build-8f6f0d81ee3a/output/aarch64-linux-gnu/bitcoin-8f6f0d81ee3a-aarch64-linux-gnu.tar.gz
e775a9e9b23be44b5c7e7121e88124746836d5bdeda1cd9ba693080d9f3a52a8 guix-build-8f6f0d81ee3a/output/arm-linux-gnueabihf/SHA256SUMS.part
8289f0770333d800e414747026c0fb105d95f389f6c8d901c1041cc65272fb02 guix-build-8f6f0d81ee3a/output/arm-linux-gnueabihf/bitcoin-8f6f0d81ee3a-arm-linux-gnueabihf-debug.tar.gz
e40256c5fb1b9a137845a50fc051f92c3e4cc013b0875a71c62af32f7024af9d guix-build-8f6f0d81ee3a/output/arm-linux-gnueabihf/bitcoin-8f6f0d81ee3a-arm-linux-gnueabihf.tar.gz
c8db222e54e78b27a8a5d3a373a9bbafa51ed29a1fda5c19e8b0eac819b002f2 guix-build-8f6f0d81ee3a/output/arm64-apple-darwin/SHA256SUMS.part
52d4063af628467605fcf533205705b38237a0cc60cafbec224ca8cf4a644738 guix-build-8f6f0d81ee3a/output/arm64-apple-darwin/bitcoin-8f6f0d81ee3a-arm64-apple-darwin-unsigned.dmg
103d80180a9f38e7c903d0b6581e4bb5130c640fac1fd5019eee7fa90e303c1d guix-build-8f6f0d81ee3a/output/arm64-apple-darwin/bitcoin-8f6f0d81ee3a-arm64-apple-darwin-unsigned.tar.gz
a8f0a89c4d4b1d05e6ea968dde3b13368999dfc1c3ea765e81fd3c4db46197b3 guix-build-8f6f0d81ee3a/output/arm64-apple-darwin/bitcoin-8f6f0d81ee3a-arm64-apple-darwin.tar.gz
726d2671bbed2355c083b8516faa5d8e0422fab6cb38a135f68ee011f9e09af5 guix-build-8f6f0d81ee3a/output/dist-archive/bitcoin-8f6f0d81ee3a.tar.gz
955fff1c9998bb04bcf1afe9b467590960206e9c512b3446ecdd701e251bb419 guix-build-8f6f0d81ee3a/output/powerpc64-linux-gnu/SHA256SUMS.part
e95cdeda727d641c002755c4a3e3b69049a35f1bff4867ac14320585d65595c4 guix-build-8f6f0d81ee3a/output/powerpc64-linux-gnu/bitcoin-8f6f0d81ee3a-powerpc64-linux-gnu-debug.tar.gz
21bda341cd8af44bc731cf7e3637322a92032e7a956acdde25ea6e59989c67b9 guix-build-8f6f0d81ee3a/output/powerpc64-linux-gnu/bitcoin-8f6f0d81ee3a-powerpc64-linux-gnu.tar.gz
6f90c38998696f61c373c3546bcc03e6b5ecfbe3b9fec9a7c75d601b3175b698 guix-build-8f6f0d81ee3a/output/powerpc64le-linux-gnu/SHA256SUMS.part
7166c2354b8777464bf8c5c3d7e4a171d00b5e0617635fa8b12c4d47ad619e84 guix-build-8f6f0d81ee3a/output/powerpc64le-linux-gnu/bitcoin-8f6f0d81ee3a-powerpc64le-linux-gnu-debug.tar.gz
8c879a3ae9fefc1071d0b6ea3b0cf858295386860b10079b472b526abfdcd2b5 guix-build-8f6f0d81ee3a/output/powerpc64le-linux-gnu/bitcoin-8f6f0d81ee3a-powerpc64le-linux-gnu.tar.gz
7dc7153d3c180308d873cb20320e8a6221cec81d8018da85683870168380eef7 guix-build-8f6f0d81ee3a/output/riscv64-linux-gnu/SHA256SUMS.part
c37b79e33b9a318d3acee9114cdf057ee518abaa09736bd63e015d924d2c3ffb guix-build-8f6f0d81ee3a/output/riscv64-linux-gnu/bitcoin-8f6f0d81ee3a-riscv64-linux-gnu-debug.tar.gz
d25abfb09d12e74bffd7f42e95eba211317acefa4718dbea27055d905f5b6999 guix-build-8f6f0d81ee3a/output/riscv64-linux-gnu/bitcoin-8f6f0d81ee3a-riscv64-linux-gnu.tar.gz
5ffc5c97012d8ae85cb56e635760029b774ea4f57a64e41cd4bdade4ed93e619 guix-build-8f6f0d81ee3a/output/x86_64-apple-darwin/SHA256SUMS.part
ecf96275016e82af2c1a4842578feac286de9db8b7f5e4266cf877cb29da1da8 guix-build-8f6f0d81ee3a/output/x86_64-apple-darwin/bitcoin-8f6f0d81ee3a-x86_64-apple-darwin-unsigned.dmg
50bee378ed88471dc326730564ca24cea2625ce1477b82881cda572f0a8913cc guix-build-8f6f0d81ee3a/output/x86_64-apple-darwin/bitcoin-8f6f0d81ee3a-x86_64-apple-darwin-unsigned.tar.gz
f4215a018f18e3639c50f10909af3ceff6982abf8b292fd88fa5d690b06d704a guix-build-8f6f0d81ee3a/output/x86_64-apple-darwin/bitcoin-8f6f0d81ee3a-x86_64-apple-darwin.tar.gz
ee5278c8afc7ead80853aff69c1bbd624ef078428076f0e92b0ad35931036b3f guix-build-8f6f0d81ee3a/output/x86_64-linux-gnu/SHA256SUMS.part
daed3889107ffe8b3ec2c59abff93d4b92a4dff382457485d29489a0e9421965 guix-build-8f6f0d81ee3a/output/x86_64-linux-gnu/bitcoin-8f6f0d81ee3a-x86_64-linux-gnu-debug.tar.gz
f1acd6b1d296f2de5ff838fe3fb82035f2774485b06678ecdd461e631ebbe092 guix-build-8f6f0d81ee3a/output/x86_64-linux-gnu/bitcoin-8f6f0d81ee3a-x86_64-linux-gnu.tar.gz
3e9f9f92e4de995c9029f17962c33e317f7000df9c1afa2a447b65ac98c27f4b guix-build-8f6f0d81ee3a/output/x86_64-w64-mingw32/SHA256SUMS.part
4b50a73917450770c793bfc787a6785c7389ce02bd25368db9a1445da07bb7b1 guix-build-8f6f0d81ee3a/output/x86_64-w64-mingw32/bitcoin-8f6f0d81ee3a-win64-debug.zip
832ddec19b8c5698cc3497f93fc59f0f72b0d7a3f313d46c2c1c52b5badf19fd guix-build-8f6f0d81ee3a/output/x86_64-w64-mingw32/bitcoin-8f6f0d81ee3a-win64-setup-unsigned.exe
d9bc2dabd0cff8e9ee6ccb309bee34a6faa1298771c0cc9bff8f948d34ec047e guix-build-8f6f0d81ee3a/output/x86_64-w64-mingw32/bitcoin-8f6f0d81ee3a-win64-unsigned.tar.gz
55cc5607d3fdf113fde463d87c5dd895c305ba0313e56bba1b0875a8a78c65a7 guix-build-8f6f0d81ee3a/output/x86_64-w64-mingw32/bitcoin-8f6f0d81ee3a-win64.zip
```
ACKs for top commit:
hebasto:
ACK 8f6f0d81ee
Tree-SHA512: f6fd4b9ed37ad93c7a5df4ca17f1ae5b8705f5dc4a377c8e01c6376b1818980534a233a08f2a20c4ff851a25f660ebb89c7416b93f6f039747194661b00c75ed
32e2ffc393 Remove the syscall sandbox (fanquake)
Pull request description:
After initially being merged in #20487, it's no-longer clear that an internal syscall sandboxing mechanism is something that Bitcoin Core should have/maintain, especially when compared to better maintained/supported alterantives, i.e [firejail](https://github.com/netblue30/firejail).
There is more related discussion in #24771.
Note that given where it's used, the sandbox also gets dragged into the kernel.
If it's removed, this should not require any sort of deprecation, as this was only ever an opt-in, experimental feature.
Closes#24771.
ACKs for top commit:
davidgumberg:
crACK 32e2ffc393
achow101:
ACK 32e2ffc393
dergoegge:
ACK 32e2ffc393
Tree-SHA512: 8cf71c5623bb642cb515531d4a2545d806e503b9d57bfc15a996597632b06103d60d985fd7f843a3c1da6528bc38d0298d6b8bcf0be6f851795a8040d71faf16
This replaces (but does not collide with) the previous bind_on_load. There
is technically no need to opt-in to this functionality as long as >= MacOS 11.0
is being targetted, but it will be helpful to see in the logs.
After initially being merged in #20487, it's no-longer clear that an
internal syscall sandboxing mechanism is something that Bitcoin Core
should have/maintain, especially when compared to better
maintained/supported alterantives, i.e firejail.
Note that given where it's used, the sandbox also gets dragged into the
kernel.
There is some related discussion in #24771.
This should not require any sort of deprecation, as this was only ever
an opt-in, experimental feature.
Closes#24771.
Disable boost multi index safe mode by default when configuring with
--enable-debug.
This option can cause transactions to take a long time to be accepted
into the mempool under certain conditions; iterator destruction takes
O(n) time vs O(1) as they are stored in a singly linked list. See
27586 for more information.
Re-enable it on the CI builds which previously had it enabled.
Re-enable it on the msan fuzz target so that we have fuzz tasks testing
with it enabeld and disabled in this repo.
5228223e1f ci: remove MSAN getrandom syscall workaround (fanquake)
d5e06919db random: switch to using getrandom() directly (fanquake)
c2ba3f5b0c random: add [[maybe_unused]] to GetDevURandom (fanquake)
c13c97dbf8 random: getentropy on macOS does not need unistd.h (fanquake)
Pull request description:
This requires a linux kernel of `3.17`+, which seems entirely
reasonable. `3.17` went EOL in 2015, and the last supported `3.x` kernel
(`3.16`) went EOL > 4 years ago, in 2020. For reference, the current
oldest maintained kernel is `4.14` (released 2017, going EOL Jan 2024).
Support for `getrandom()` (and `getentropy()`) was added to
glibc `2.25` https://sourceware.org/legacy-ml/libc-alpha/2017-02/msg00079.html:
> * The getentropy and getrandom functions, and the <sys/random.h> header
file have been added.
and we already require `2.27` or later.
All that being said, I don't think you would encounter a current day (+~6 months from now)
system, running with kernel headers older than 3.17 (released 2014) but also having a
glibc of 2.27+ (released 2018)?
Removing this (our only) use of `syscall()` also means we can drop a workaround in our MSAN jobs.
If this is merged, I'll drop the [same workaround in oss-fuzz](25946a5448/projects/bitcoin-core/build.sh (L49-L56)).
ACKs for top commit:
josibake:
ACK 5228223e1f
hebasto:
ACK 5228223e1f, I've tested build system changes on Ubuntu 22.04 and macOS Monterey 12.6.6 (x86_64).
Tree-SHA512: cc978e08510c461b875ca8c08ae176b4519fa1108f0efd74dcb7474518945357e0184e54423282c9a496de195e4ddc3e221ee78623bd63e24c50cc86acdf32e2
fa5831bd6f build: Do not define `ENABLE_ZMQ` when ZMQ is not available (Hennadii Stepanov)
Pull request description:
A new behavior is consistent with the other optional dependencies.
The source code contains `#if ENABLE_ZMQ` lines only:
```
$ git grep ENABLE_ZMQ -- src/*.cpp
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
```
Change in description line -- "Define to 1..." --> "Define this symbol.." -- is motivated by the fact that the actual value of the defined `ENABLE_ZMQ` macro does not matter at all.
Related to:
- https://github.com/bitcoin/bitcoin/issues/16419
- https://github.com/bitcoin/bitcoin/pull/25302
ACKs for top commit:
TheCharlatan:
ACK fa5831bd6f
jarolrod:
ACK fa5831bd6f
Tree-SHA512: 5e72ff0d34c4b33205338daea0aae8d7aa0e48fd633e21af01af32b7ddb0532ef68dd3dd74deb2c1d2599691929617e8c09676bcbaaf7d669b88816f866f1db2
This requires a linux kernel of 3.17.0+, which seems entirely
reasonable. 3.17 went EOL in 2015, and the last supported 3.x kernel
(3.16) went EOL > 4 years ago, in 2020. For reference, the current
oldest maintained kernel is 4.14 (released 2017, EOL Jan 2024).
Support for `getrandom()` (and `getentropy()`) was added to
glibc 2.25, https://sourceware.org/legacy-ml/libc-alpha/2017-02/msg00079.html,
and we already require 2.27+.
All that being said, I don't think you would encounter a current day
system, running with kernel headers older than 3.17 (released 2014) but
also having a glibc of 2.27+ (released 2018).
Remove it. Make this change, so in a future commit, we can
combine #ifdefs, and avoid duplicate <sys/random.h> includes once we
switch to using getrandom directly.
Also remove the comment about macOS 10.12. We already require macOS >
10.15, so it is redundant.
b53cab0083 build: Detect USDT the same way how it is used in the code (Hennadii Stepanov)
Pull request description:
In the code we do not use string literals.
Also a check for `DTRACE_PROBE7` macro has been added as not all systems define`DTRACE_PROBE{6,7,8,9,10,11,12}` macros (e.g., FreeBSD).
ACKs for top commit:
0xB10C:
ACK b53cab0083
Tree-SHA512: 74f49424d57bf1929f2b09edba1449cef5a1a2448161952da35302343f3003d5bedeab1417e166b656c5f629303e2de888550b1219e886a1b991b12b9c880794
libtool gets a false-positive from the warning produced by lld -single_module
because it is already the default and unneeded.
Skip the check unconditionally for Darwin linkers.
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
