aboutsummaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2024-01-26Merge bitcoin/bitcoin#28875: build: Pass sanitize flags to instrument ↵fanquake
`libsecp256k1` code cbea49c0d32badb975fbf22d44f8e25cc7972af7 build: Pass sanitize flags to instrument `libsecp256k1` code (Hennadii Stepanov) Pull request description: This PR is a revived https://github.com/bitcoin/bitcoin/pull/27991 with an addressed [comment](https://github.com/bitcoin/bitcoin/pull/27991#discussion_r1252148488). Fixes https://github.com/bitcoin/bitcoin/issues/27990. Might be tested as follows: ``` $ ./autogen.sh && ./configure --enable-fuzz --with-sanitizers=fuzzer CC=clang-13 CXX=clang++-13 $ make clean > /dev/null && make $ objdump --disassemble=secp256k1_xonly_pubkey_serialize src/test/fuzz/fuzz | grep __sanitizer_cov 1953bd0:e8 bb c6 05 ff call 9b0290 <__sanitizer_cov_trace_const_cmp8> 1953d32:e8 69 c4 05 ff call 9b01a0 <__sanitizer_cov_trace_pc_indir> 1953d58:e8 43 c4 05 ff call 9b01a0 <__sanitizer_cov_trace_pc_indir> 1953d82:e8 19 c4 05 ff call 9b01a0 <__sanitizer_cov_trace_pc_indir> ``` ACKs for top commit: fanquake: ACK cbea49c0d32badb975fbf22d44f8e25cc7972af7 dergoegge: reACK cbea49c0d32badb975fbf22d44f8e25cc7972af7 Tree-SHA512: 801994e75b711d20eaf0d675f378da07d693f4a7de026efd93860f5f1deabed855a83eca3561725263e4fe605fcc5f91eb73c021ec91c831864e6deb575e3885
2024-01-19build: Pass sanitize flags to instrument `libsecp256k1` codeHennadii Stepanov
Also a new UBSan suppression has been added.
2024-01-16build: fix optimisation flags used for --coveragefanquake
-O0 is just overriding -Og.
2024-01-16build: add sanitizer flags to configure outputfanquake
2024-01-16build: always set -g -O2 in CORE_CXXFLAGSfanquake
This avoids cases of missing -O2, when *FLAGS has been overriden. Removes the need for duplicate code to clear autoconf defaults. Also, move CORE_CXXFLAGS before DEBUG_CXXFLAGS, so that -O2 is always overriden if debugging etc.
2024-01-16Merge bitcoin/bitcoin#29185: build: remove `--enable-lto`fanquake
2d1b1c7daeeada3f737e62ceb2db7484cde5ff4e build: remove --enable-lto (fanquake) Pull request description: This has outlived its usefulness, doesn't gel well with newer compilers & `-flto` related options, i.e thin vs full, or `=auto`, and having `-flto` as the only option means that sometimes this just needs to be worked around, i.e in oss-fuzz: https://github.com/google/oss-fuzz/blob/master/projects/bitcoin-core/build.sh. While it was convenient when `-flto` was newer, support for `-flto` is now in all compilers we use, and there's also no-longer any real need for us to treat `-flto` different to any other optimization option. Remove it, to remove build complexity, and so there's no need to port a similar option to CMake. Note that the LTO option remains in depends, because we still a way to build packages that have LTO specific patches/options. ACKs for top commit: TheCharlatan: ACK 2d1b1c7daeeada3f737e62ceb2db7484cde5ff4e hebasto: ACK 2d1b1c7daeeada3f737e62ceb2db7484cde5ff4e. Tree-SHA512: 91812de7da35346f51850714a188fcffbac478bc8b348bf756c2555fcbde86ba622ac2fb77d294dea0378c741d3656f06121ef3a795aeed63fd170fc31bfa5af
2024-01-12Merge bitcoin/bitcoin#29208: build: Bump clang minimum supported version to 14fanquake
aaaace2fd1299939c755c281b787df0bbf1747a0 fuzz: Assume presence of __builtin_*_overflow, without checks (MarcoFalke) fa223ba5eb764fe822229a58d4d44d3ea83d0793 Revert "build: Fix undefined reference to __mulodi4" (MarcoFalke) fa7c751bd923cd9fb4790fe7fb51fafa2faa1db6 build: Bump clang minimum supported version to 14 (MarcoFalke) Pull request description: Most supported operating systems ship with clang-14 (or later), so bump the minimum to that and allow new code to drop workarounds for previous clang bugs. For reference: * https://packages.debian.org/bookworm/clang (`clang-14`) * https://packages.ubuntu.com/jammy/clang (`clang-14`) * CentOS-like 8/9 Stream: All Clang versions from 15 to 17 * FreeBSD 12/13: All Clang versions from 15 to 16 * OpenSuse Tumbleweed ships with https://software.opensuse.org/package/clang (`clang17`); No idea about OpenSuse Leap On operating systems where the clang version is not shipped by default, the user would have to use GCC, or install clang in a different way. For example: * https://packages.debian.org/bullseye/g++ (g++-10) * https://packages.ubuntu.com/focal/g++-10 * https://apt.llvm.org/, or nix, or guix, or compile clang from source, ... ACKs for top commit: fanquake: ACK aaaace2fd1299939c755c281b787df0bbf1747a0 Tree-SHA512: 81d066b14cc568d27312f1cc814b09540b038a10a0a8e9d71fc9745b024fb6c32a959af673e6819b817ea7cef98da4abfa63dff16cffb7821b40083016b0291f
2024-01-10doc: upgrade Bitcoin Core license to 202422388o⚡️
2024-01-09Revert "build: Fix undefined reference to __mulodi4"MarcoFalke
This reverts commit e4c8bb62e4a6873c45f42d0d2a24927cb241a0ea.
2024-01-07build: Fix `-Xclang -internal-isystem` optionHennadii Stepanov
LLVM Clang >=16.0 and Apple Clang >=15.0 do not recognize `-Xclang -internal-isystem/usr/local/include` anymore. For example, see: https://github.com/llvm/llvm-project/commit/cbbe1d44546db52c71c9a2b18f85b87ae82df9e7
2024-01-05build: remove --enable-ltofanquake
This has outlived its usefulness, doesn't gel well with newer compilers & `-flto` related options, i.e thin vs full, or `=auto`, and having `-flto` as the only option means that sometimes this just needs to be worked around, i.e in oss-fuzz: https://github.com/google/oss-fuzz/blob/master/projects/bitcoin-core/build.sh. While it was convenient when `-flto` was newer, support for `-flto` is now in all compilers we use, and there's also no-longer any real need for us to treat `-flto` different to any other optimization option. Remove it, to remove build complexity, and so there's no need to port a similar option to CMake. Note that the LTO option remains in depends, because we still a way to build packages that have LTO specific patches/options. If we decide to merge this, I'll follow up downstream in oss-fuzz first, to make sure we don't break the build.
2023-12-13Merge bitcoin/bitcoin#29066: Bump minimum required Boost version due to ↵fanquake
migration to C++20 49a90915aa3ee8e3a7e163f23a55de931faf8523 build: Bump minimum required Boost to 1.73.0 to support C++20 (Hennadii Stepanov) Pull request description: Boost versions <1.73 have C++20-specific bugs that were fixed in the following commits: - https://github.com/boostorg/signals2/commit/15fcf213563718d2378b6b83a1614680a4fa8cec - https://github.com/boostorg/test/commit/495c095dc063052ce54f2fe9217fe0fc69ced5f1 I tested [`libboost1.71-dev`](https://packages.ubuntu.com/focal/libboost1.71-dev) in Ubuntu 20.04 and Boost 1.71, 1.72, 1.73 in our depends build system. Closes https://github.com/bitcoin/bitcoin/issues/29063. ACKs for top commit: fanquake: ACK 49a90915aa3ee8e3a7e163f23a55de931faf8523 Tree-SHA512: b8ebc08af85abfa3fda70961bd1136ee9e5149dd76a3f901e43acba624d231971873cba5cbf30837f9e5ab58790b8330f241a76cb76d8cf5dce5ad0cca33fba8
2023-12-13Merge bitcoin/bitcoin#28967: build: disable external-signer for Windowsfanquake
308aec3e5655327d98e0428d8205d246f24d6af5 build: disable external-signer for Windows (fanquake) 35537318a19360ddf1ea8f0c1e6d8ad49e635516 ci: remove --enable-external-signer from win64 job (fanquake) Pull request description: It's come to light that Boost ASIO (a Boost Process sub dep) has in some instances, been quietly initialising our network stack on Windows (see PR https://github.com/bitcoin/bitcoin/pull/28486 and discussion in https://github.com/bitcoin/bitcoin/issues/28940). This has been shielding a bug in our own code, but the larger issue is that Boost Process/ASIO is running code before main, and doing things like setting up networking. This undermines our own assumptions about how our binary works, happens before we run any sanity checks, and before we call our own code to setup networking. Note that ASIO also calls WSAStartup with version `2.0`, whereas we call with `2.2`. It's also not clear why a feature like external signer would have a dependency that would be doing anything network/socket related, given it only exists to spawn a local process. See also the discussion in https://github.com/bitcoin/bitcoin/issues/24907. Note that the maintaince of Boost Process in general, has not really improved. For example, rather than fixing bugs like https://github.com/boostorg/process/issues/111, i.e, https://github.com/boostorg/process/pull/317, the maintainer chooses to just wrap exception causing overflows in try-catch blocks: https://github.com/boostorg/process/commit/0c42a58eacab6a96b19196e399307bad8a938a27. These changes get merged in large, unreviewed PRs, i.e https://github.com/boostorg/process/pull/319. This PR disables external-signer on Windows for now. If, in future, someone changes how Boost Process works, or replaces it entirely with some properly reviewed and maintained code, we could reenable this feature on Windows. ACKs for top commit: hebasto: re-ACK 308aec3e5655327d98e0428d8205d246f24d6af5. TheCharlatan: ACK 308aec3e5655327d98e0428d8205d246f24d6af5 Tree-SHA512: 7405f7fc9833eeaacd6836c4e5b1c1a7845a40c1fdd55c1060152f8d8189e4777464fde650e11eb1539556a75dddf49667105987078b1457493ee772945da66e
2023-12-12build: Bump minimum required Boost to 1.73.0 to support C++20Hennadii Stepanov
Boost versions <1.73 have C++20-specific bugs that were fixed in the following commits: - https://github.com/boostorg/signals2/commit/15fcf213563718d2378b6b83a1614680a4fa8cec - https://github.com/boostorg/test/commit/495c095dc063052ce54f2fe9217fe0fc69ced5f1
2023-12-11Merge bitcoin/bitcoin#28999: build: Enable -Wunreachable-codefanquake
fa8adbe7c17b16cf7ecd16eb9f3f1792e9da2876 build: Enable -Wunreachable-code (MarcoFalke) Pull request description: It seems a bit confusing to write code after a `return`. This can even lead to bugs, or incorrect code, such as https://github.com/bitcoin/bitcoin/pull/28830/files#r1415372320 . (Edit: The linked instance is not found by clang's `-Wunreachable-code`). Fix all issues by enabling `-Wunreachable-code`. This flag also enables `-Wunreachable-code-loop-increment`, according to https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code, so remove that. ACKs for top commit: ajtowns: > ACK [fa8adbe](https://github.com/bitcoin/bitcoin/commit/fa8adbe7c17b16cf7ecd16eb9f3f1792e9da2876) stickies-v: ACK fa8adbe7c17b16cf7ecd16eb9f3f1792e9da2876 jonatack: ACK fa8adbe7c17b16cf7ecd16eb9f3f1792e9da2876 tested with arm64 clang 17.0.6 Tree-SHA512: 12a2f74b69ae002e62ae08038f7458837090a12051a4c154d05ae4bb26fb19fc1fa76c63aedf2b3fbb36f048c593ca3b8c0efe03fe93cf07a0fd114fc84ce1e7
2023-12-07build: Require C++20 compilerMarcoFalke
2023-12-05build: Enable -Wunreachable-codeMarcoFalke
2023-12-01build: disable external-signer for Windowsfanquake
It's come to light that Boost ASIO (a Boost Process sub dep) has in some instances, been queitly initialising our network stack on Windows (see PR #28486 and discussion in #28940). This has been shielding a bug in our own code, but the larger issue is that Boost Process/ASIO is running code before main, and doing things like setting up networking. This undermines our own assumptions about how our binary works, happens before we get to run any sanity checks, and also runs before we call our own code to setup networking. It's also not clear why a feature like external signer would have a dependency that would be doing anything network/socket related, given it only exists to spawn a local process.
2023-11-22Merge bitcoin/bitcoin#28919: build: Fix regression in "ARMv8 CRC32 ↵fanquake
intrinsics" test 228d6a2969e4fcee573c9df7aad31550eab9c8d4 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 @ d752349029ec7a76f1fd440db2ec2e458d0f3c99: ``` 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 228d6a2969e4fcee573c9df7aad31550eab9c8d4 Tree-SHA512: 4c27ca8acb953bf56e972d907a282ee19e3f30f7a4bf8a9822395fe0e28977cd6233e8b65b4a25cc1d3d5ff6a796d7af07653e18531c44ee3efaff1563d96d32
2023-11-22Merge bitcoin/bitcoin#28461: build: Windows SSP roundupfanquake
f95af98128f17002bf137a48441167020f3ef9bb guix: default ssp for Windows GCC (fanquake) 95d55b96c2cfd2a0d5a246d4a9eff9d0744ba223 guix: remove ssp workaround from Windows GCC (fanquake) 8f43302a0a1bb79129933e4cc174bf8d8d59ec15 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 f95af98128f17002bf137a48441167020f3ef9bb, I've verified binaries from `bitcoin-f95af98128f1-win64.zip` on Windows 11 Pro 23H2. TheCharlatan: ACK f95af98128f17002bf137a48441167020f3ef9bb Tree-SHA512: 71169ec513cfe692dfa7741d2bf37b45da05627c0af1cbd50cf8c3c04cc21c4bf88f3284532bddc1e3e648391ec78dbaca5170987a13c21ac204a7bcaf27f349
2023-11-20build: Fix regression in "ARMv8 CRC32 intrinsics" testHennadii Stepanov
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.
2023-11-14depends: remove PYTHONPATH from config.sitefanquake
We no-longer need this, as we no-longer build python packages. Effectively reverts de619a37fd18a17225c8a10b828fc61958abe4cf.
2023-11-13build: remove explicit libssp linking from Windows buildfanquake
2023-11-09build: Add an old hack to remove bind_at_load from libtool.Cory Fields
Similar to a98356fee8a44d7d1cb37f22c876fff8f244365e.
2023-11-09build: remove -bind_at_load usagefanquake
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`.
2023-10-31build: remove potential for duplciate natpmp linkingfanquake
Consolidate the lib checking logic to be the same as miniupnpc.
2023-10-31build: remove duplicate -lminiupnpc linkingfanquake
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.
2023-10-30Always enable -Wsuggest-overrideMarcoFalke
2023-10-24Merge bitcoin/bitcoin#28211: Bump python minimum supported version to 3.9fanquake
fa25e8b0a1610553014c786428f146ef9c694678 doc: Recommend lint image build on every call (MarcoFalke) faf70c1f330a92612cf381d32c791e9ba445d3f2 Bump python minimum version to 3.9 (MarcoFalke) fa8996b930886da712c09ffe4b58016b36c2ae5b 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 fa25e8b0a1610553014c786428f146ef9c694678 jamesob: ACK fa25e8b0a1610553014c786428f146ef9c694678 ([`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
2023-10-24build: bump version to 26.99fanquake
2023-10-18build: move -fstack-reuse=none to CORE_CXXFLAGSfanquake
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`.
2023-10-10build: add `-mbranch-protection=bti` to aarch64 hardening flagsfanquake
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.
2023-09-15build: remove dmg dependenciesfanquake
2023-09-15macdeploy: remove DMG generation from deploy scriptfanquake
2023-09-15build: produce a .zip for macOS distributionHennadii Stepanov
Instead of a .dmg. Co-authored-by: fanquake <fanquake@gmail.com>
2023-09-12doc: Clarify that -fstack-reuse=all bugs exist on all versions of GCCMarcoFalke
2023-08-30build: use -muse-unaligned-vector-move for Windowsfanquake
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.
2023-08-29Bump python minimum version to 3.9MarcoFalke
2023-07-27Merge bitcoin/bitcoin#28092: ci: document that -Wreturn-type has been fixed ↵fanquake
upstream (mingw-w64) 08eb5f1b67e2af009549717eb5c66b7d7905731f ci: document that -Wreturn-type has been fixed upstream (Windows) (fanquake) Pull request description: `noreturn` attributes have been added to the mingw-w64 headers, https://github.com/mingw-w64/mingw-w64/commit/1690994f515910a31b9fb7c7bd3a52d4ba987abe, 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 08eb5f1b67e2af009549717eb5c66b7d7905731f Tree-SHA512: 9cd4310a96abd87bf8ceb37949ad0259fe4adee3367c604f4c4ad521a0cf09bdcc5dd305db19a0f45ce74c85178b0d739e2fca5ad0fc841ac935523a23b28a7f
2023-07-18build: adapt Windows builds for libsecp256k1 build changesfanquake
See https://github.com/bitcoin-core/secp256k1/pull/1367.
2023-07-18ci: document that -Wreturn-type has been fixed upstream (Windows)fanquake
`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): https://github.com/mingw-w64/mingw-w64/commit/1690994f515910a31b9fb7c7bd3a52d4ba987abe. 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.
2023-07-17Merge bitcoin/bitcoin#28069: guix: Remove librt usage from release binariesfanquake
8f6f0d81ee3a9ea582e9c9cf986613da86760098 guix: backport glibc patch to prevent redundant librt link (fanquake) e14473299cd3e55ca177876df957927937648cd6 contrib: remove librt from release deps (fanquake) e64e17830ad9323b8e5f562b1e457403b1ddaf3a 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 8f6f0d81ee3a9ea582e9c9cf986613da86760098 Tree-SHA512: f6fd4b9ed37ad93c7a5df4ca17f1ae5b8705f5dc4a377c8e01c6376b1818980534a233a08f2a20c4ff851a25f660ebb89c7416b93f6f039747194661b00c75ed
2023-07-16doc: update windows -fstack-clash-protection docfanquake
Now that changes have been made in GCC, to fix the build failures. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458.
2023-07-12build: remove check for gettimeofday & librtfanquake
2023-06-27Merge bitcoin/bitcoin#27896: Remove the syscall sandboxAndrew Chow
32e2ffc39374f61bb2435da507f285459985df9e 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 https://github.com/bitcoin/bitcoin/pull/27896/commits/32e2ffc39374f61bb2435da507f285459985df9e achow101: ACK 32e2ffc39374f61bb2435da507f285459985df9e dergoegge: ACK 32e2ffc39374f61bb2435da507f285459985df9e Tree-SHA512: 8cf71c5623bb642cb515531d4a2545d806e503b9d57bfc15a996597632b06103d60d985fd7f843a3c1da6528bc38d0298d6b8bcf0be6f851795a8040d71faf16
2023-06-22build: explicitly opt-in to new fixup_chains functionality for darwinCory Fields
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.
2023-06-16Remove the syscall sandboxfanquake
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.
2023-06-15build: suppress external warnings by defaultfanquake
2023-05-23build: disable boost multi index safe modewillcl-ark
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.
2023-05-22Merge bitcoin/bitcoin#27699: random: drop syscall wrapper usage for getrandom()fanquake
5228223e1ff2af29e6e77668ce3288005c2adbbc ci: remove MSAN getrandom syscall workaround (fanquake) d5e06919db5e221bfef445c5a40c88de72dc5869 random: switch to using getrandom() directly (fanquake) c2ba3f5b0c7d0eece7d16d1ffc125d8a6a9297af random: add [[maybe_unused]] to GetDevURandom (fanquake) c13c97dbf846cf0e6a5581ac414ef96a215b0dc6 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](https://github.com/google/oss-fuzz/blob/25946a544856413d31d9cbb3a366a4aef5a8fd60/projects/bitcoin-core/build.sh#L49-L56). ACKs for top commit: josibake: ACK https://github.com/bitcoin/bitcoin/pull/27699/commits/5228223e1ff2af29e6e77668ce3288005c2adbbc hebasto: ACK 5228223e1ff2af29e6e77668ce3288005c2adbbc, I've tested build system changes on Ubuntu 22.04 and macOS Monterey 12.6.6 (x86_64). Tree-SHA512: cc978e08510c461b875ca8c08ae176b4519fa1108f0efd74dcb7474518945357e0184e54423282c9a496de195e4ddc3e221ee78623bd63e24c50cc86acdf32e2
generated by cgit v1.2.3 (git 2.26.2) at 2024-08-27 21:59:51 +0000