aboutsummaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2024-04-12build: remove minisketch clz checkfanquake
2024-04-10Merge bitcoin/bitcoin#28981: Replace Boost.Process with cpp-subprocessmerge-script
d5a715536e497c160a2520f81334aab6c7490213 build: remove boost::process dependency for building external signer support (Sebastian Falbesoner) 70434b1c443d9251a880d0193af771f574c40617 external_signer: replace boost::process with cpp-subprocess (Sebastian Falbesoner) cc8b9875b104c31f0a5b5e4195a8278ec55f35f7 Add `cpp-subprocess` header-only library (Hennadii Stepanov) Pull request description: Closes https://github.com/bitcoin/bitcoin/issues/24907. This PR is based on **theStack**'s [work](https://github.com/bitcoin/bitcoin/issues/24907#issuecomment-1466087049). The `subprocess.hpp` header has been sourced from the [upstream repo](https://github.com/arun11299/cpp-subprocess) with the only modification being the removal of convenience functions, which are not utilized in our codebase. Windows-related changes will be addressed in subsequent follow-ups. ACKs for top commit: achow101: reACK d5a715536e497c160a2520f81334aab6c7490213 Sjors: re-tACK d5a715536e497c160a2520f81334aab6c7490213 theStack: Light re-ACK d5a715536e497c160a2520f81334aab6c7490213 fanquake: ACK d5a715536e497c160a2520f81334aab6c7490213 - with the expectation that this code is going to be maintained as our own. Next PRs should: Tree-SHA512: d7fb6fecc3f5792496204190afb7d85b3e207b858fb1a75efe483c05260843b81b27d14b299323bb667c990e87a07197059afea3796cf218ed8b614086bd3611
2024-04-06Merge bitcoin/bitcoin#29815: crypto: chacha20: always use our fallback ↵fanquake
timingsafe_bcmp rather than libc's 2d1819455cb4c516f6cdf81c11e869a23dee3e6b crypto: chacha20: always use our fallback timingsafe_bcmp rather than libc's (Cory Fields) Pull request description: Looking at libc sources, apple and openbsd implementations match our naive fallback. Only FreeBSD (and only x86_64) seems to [implement an optimized version](https://github.com/freebsd/freebsd-src/blob/main/lib/libc/amd64/string/timingsafe_bcmp.S). It's not worth the hassle of using a platform-specific function for such little gain. Additionally, as mentioned below, this is the only case outside of sha2 that requires an autoconf check, and I have upcoming PRs to remove the sha2 ones. Apple's [impl is unoptimized](https://opensource.apple.com/source/Libc/Libc-1244.1.7/string/FreeBSD/timingsafe_bcmp.c.auto.html). As-is [OpenBSD's impl](https://github.com/openbsd/src/blob/master/lib/libc/string/timingsafe_bcmp.c). Relevant IRC conversation with sipa: > \<cfields\> sipa: chacha20poly1305.cpp uses libc's timingsafe_bcmp when possible. But looking around at apple/freebsd/openbsd, I don't see any impl that doesn't use the naive implementation that matches our fallback... > \<cfields\> is there any reason to belive there's an optimized impl somewhere that we're actually hitting? > \<cfields\> asking because after cleaning up sha2, timingsafe_bcmp is the last autoconf check that remains in all of crypto. It'd make life easy if we could just always use our internal one. > \<cfields\> *all of crypto/ > \<sipa\> cfields: let's get rid of the dependency then > \<sipa\> it's a trivial function > \<sipa\> and if we need it for some platforms, no real reason not to use it on all After the above discusstion, I did end up finding the x86_64-optimized FreeBSD impl, but I don't think that's all that significant. ACKs for top commit: sipa: utACK 2d1819455cb4c516f6cdf81c11e869a23dee3e6b fanquake: ACK 2d1819455cb4c516f6cdf81c11e869a23dee3e6b TheCharlatan: ACK 2d1819455cb4c516f6cdf81c11e869a23dee3e6b theStack: ACK 2d1819455cb4c516f6cdf81c11e869a23dee3e6b Tree-SHA512: b9583e19ac2f77c5d572aa5b95bc4b53669d5717e5708babef930644980de7c5d06a9c7decd5c2b559d70b8597328ecfe513375e3d8c3ef523db80012dfe9266
2024-04-05Merge bitcoin/bitcoin#29081: refactor: Remove gmtime*fanquake
fa9f36babaceba6ab2f88e64bc4bc2956f58871f build: Remove HAVE_GMTIME_R (MarcoFalke) fa72dcbfa56177ca878375bae7c7bca6ca6a1f40 refactor: FormatISO8601* without gmtime* (MarcoFalke) fa2c486afc8501f2678cc19c9e9518a23c4ebcbd Revert "time: add runtime sanity check" (MarcoFalke) Pull request description: Now that the `ChronoSanityCheck` has passed for everyone with C++17 and is guaranteed by C++20 to always pass, remove it. Also, remove `gmtime_r` and `gmtime_s` and replace them with `year_month_day`+`hh_mm_ss` from C++20. ACKs for top commit: sipa: utACK fa9f36babaceba6ab2f88e64bc4bc2956f58871f fanquake: ACK fa9f36babaceba6ab2f88e64bc4bc2956f58871f - more std lib & even less stuff to port. Tree-SHA512: a9e7e805b757b7dade0bcc3f95273a7dc4f68622630d74838339789dd203ad7542d36b2e090a93b2bc5a7ecc383207dd7ec82c68147108bdac7ce44f088c8c9a
2024-04-05crypto: chacha20: always use our fallback timingsafe_bcmp rather than libc'sCory Fields
Looking at apple/freebsd/openbsd sources, their implementations match our naive fallback. It's not worth the hassle of using a platform-specific function for no gain.
2024-03-27build: remove boost::process dependency for building external signer supportSebastian Falbesoner
2024-03-18remove libbitcoinconsensusfanquake
This was deprecated in v27.0, for removal in v28.0. See discussion in PR #29189.
2024-03-18build: Remove HAVE_GMTIME_RMarcoFalke
2024-03-13Merge bitcoin/bitcoin#27375: net: support unix domain sockets for -proxy and ↵Ava Chow
-onion 567cec9a05e1261e955535f734826b12341684b6 doc: add release notes and help text for unix sockets (Matthew Zipkin) bfe51928911daf484ae07deb52a7ff0bcb2526ae test: cover UNIX sockets in feature_proxy.py (Matthew Zipkin) c65c0d01630b44fa71321ea7ad68d5f9fbb7aefb init: allow UNIX socket path for -proxy and -onion (Matthew Zipkin) c3bd43142eba77dcf1acd4984e437759f65e237a gui: accomodate unix socket Proxy in updateDefaultProxyNets() (Matthew Zipkin) a88bf9dedd1d8c1db0a9c8b663dab3e3c2f0f030 i2p: construct Session with Proxy instead of CService (Matthew Zipkin) d9318a37ec09fe0b002815a7e48710e530620ae2 net: split ConnectToSocket() from ConnectDirectly() for unix sockets (Matthew Zipkin) ac2ecf3182fb5ad9bcd41540b19382376114d6ee proxy: rename randomize_credentials to m_randomize_credentials (Matthew Zipkin) a89c3f59dc44eaf4f59912c1accfc0ce5d61933a netbase: extend Proxy class to wrap UNIX socket as well as TCP (Matthew Zipkin) 3a7d6548effa6cd9a4a5413b690c2fd85da4ef65 net: move CreateSock() calls from ConnectNode() to netbase methods (Matthew Zipkin) 74f568cb6fd5c74b7b9bf0ce69876430746a53b1 netbase: allow CreateSock() to create UNIX sockets if supported (Matthew Zipkin) bae86c8d318d06818aa75a9ebe3db864197f0bc6 netbase: refactor CreateSock() to accept sa_family_t (Matthew Zipkin) adb3a3e51de205cc69b1a58647c65c04fa6c6362 configure: test for unix domain sockets (Matthew Zipkin) Pull request description: Closes https://github.com/bitcoin/bitcoin/issues/27252 UNIX domain sockets are a mechanism for inter-process communication that are faster than local TCP ports (because there is no need for TCP overhead) and potentially more secure because access is managed by the filesystem instead of serving an open port on the system. There has been work on [unix domain sockets before](https://github.com/bitcoin/bitcoin/pull/9979) but for now I just wanted to start on this single use-case which is enabling unix sockets from the client side, specifically connecting to a local Tor proxy (Tor can listen on unix sockets and even enforces strict curent-user-only access permission before binding) configured by `-onion=` or `-proxy=` I copied the prefix `unix:` usage from Tor. With this patch built locally you can test with your own filesystem path (example): `tor --SocksPort unix:/Users/matthewzipkin/torsocket/x` `bitcoind -proxy=unix:/Users/matthewzipkin/torsocket/x` Prep work for this feature includes: - Moving where and how we create `sockaddr` and `Sock` to accommodate `AF_UNIX` without disturbing `CService` - Expanding `Proxy` class to represent either a `CService` or a UNIX socket (by its file path) Future work: - Enable UNIX sockets for ZMQ (https://github.com/bitcoin/bitcoin/pull/27679) - Enable UNIX sockets for I2P SAM proxy (some code is included in this PR but not tested or exposed to user options yet) - Enable UNIX sockets on windows where supported - Update Network Proxies dialog in GUI to support UNIX sockets ACKs for top commit: Sjors: re-ACK 567cec9a05e1261e955535f734826b12341684b6 tdb3: re ACK for 567cec9a05e1261e955535f734826b12341684b6. achow101: ACK 567cec9a05e1261e955535f734826b12341684b6 vasild: ACK 567cec9a05e1261e955535f734826b12341684b6 Tree-SHA512: de81860e56d5de83217a18df4c35297732b4ad491e293a0153d2d02a0bde1d022700a1131279b187ef219651487537354b9d06d10fde56225500c7e257df92c1
2024-03-07build: ignore deprecated-declaration warnings in objc++ macOS codefanquake
These come from GUI code, and haven't/aren't being fixed, see discussion in https://github.com/bitcoin-core/gui/issues/112. For now, just ignore them entirely. Note that this only applies to ObjCXX code, so will not hide any relevant warnings coming from C or CXX code (and they would be unlikely in any case). Alternative to #29362, which disables all compiler warnings, for macOS builds in the CI. Relevant output: ```bash qt/macnotificationhandler.mm:27:9: warning: 'NSUserNotification' is deprecated: first deprecated in macOS 11.0 - All NSUserNotifications API should be replaced with UserNotifications.frameworks API [-Wdeprecated-declarations] NSUserNotification* userNotification = [[NSUserNotification alloc] init]; ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:24:12: note: 'NSUserNotification' has been explicitly marked deprecated here @interface NSUserNotification : NSObject <NSCopying> { ^ qt/macnotificationhandler.mm:27:50: warning: 'NSUserNotification' is deprecated: first deprecated in macOS 11.0 - All NSUserNotifications API should be replaced with UserNotifications.frameworks API [-Wdeprecated-declarations] NSUserNotification* userNotification = [[NSUserNotification alloc] init]; ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:24:12: note: 'NSUserNotification' has been explicitly marked deprecated here @interface NSUserNotification : NSObject <NSCopying> { ^ qt/macnotificationhandler.mm:30:11: warning: 'NSUserNotificationCenter' is deprecated: first deprecated in macOS 11.0 - All NSUserNotifications API should be replaced with UserNotifications.frameworks API [-Wdeprecated-declarations] [[NSUserNotificationCenter defaultUserNotificationCenter] deliverNotification: userNotification]; ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:118:12: note: 'NSUserNotificationCenter' has been explicitly marked deprecated here @interface NSUserNotificationCenter : NSObject { ^ 3 warnings generated. ```
2024-03-06build: bump version to 27.99fanquake
2024-03-01configure: test for unix domain socketsMatthew Zipkin
Copied from https://github.com/bitcoin/bitcoin/pull/9979 Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
2024-03-01Merge bitcoin/bitcoin#29263: serialization: c++20 endian/byteswap/clz ↵fanquake
modernization 86b7f28d6c507155a9d3a15487ee883989b88943 serialization: use internal endian conversion functions (Cory Fields) 432b18ca8d0654318a8d882b28b20af2cb2d2e5d serialization: detect byteswap builtins without autoconf tests (Cory Fields) 297367b3bb062c57142747719ac9bf2e12717ce9 crypto: replace CountBits with std::bit_width (Cory Fields) 52f9bba889fd9b50a0543fd9fedc389592cdc7e5 crypto: replace non-standard CLZ builtins with c++20's bit_width (Cory Fields) Pull request description: This replaces #28674, #29036, and #29057. Now ready for testing and review. Replaces platform-specific endian and byteswap functions. This is especially useful for kernel, as it means that our deep serialization code no longer requires bitcoin-config.h. I apologize for the size of the last commit, but it's hard to avoid making those changes at once. All platforms now use our internal functions rather than libc or platform-specific ones, with the exception of MSVC. Sadly, benchmarking showed that not all compilers are capable of detecting and optimizing byteswap functions, so compiler builtins are instead used where possible. However, they're now detected via macros rather than autoconf checks. This[ matches how libc++ implements std::byteswap for c++23](https://github.com/llvm/llvm-project/blob/main/libcxx/include/__bit/byteswap.h#L26). I suggest we move/rename `compat/endian.h`, but I left that out of this PR to avoid bikeshedding. #29057 pointed out some irregularities in benchmarks. After messing with various compilers and configs for a few weeks with these changes, I'm of the opinion that we can't win on every platform every time, so we should take the code that makes sense going forward. That said, if any real-world slowdowns are caused here, we should obviously investigate. ACKs for top commit: maflcko: ACK 86b7f28d6c507155a9d3a15487ee883989b88943 📘 fanquake: ACK 86b7f28d6c507155a9d3a15487ee883989b88943 - we can finish pruning out the __builtin_clz* checks/usage once the minisketch code has been updated. This is more good cleanup pre-CMake & for the kernal. Tree-SHA512: 715a32ec190c70505ffbce70bfe81fc7b6aa33e376b60292e801f60cf17025aabfcab4e8c53ebb2e28ffc5cf4c20b74fe3dd8548371ad772085c13aec8b7970e
2024-02-29build: remove confusing and inconsistent disable-asm optionCory Fields
1. It didn't actually disable asm usage in our code. Regardless of the setting, asm is used in random.cpp and support/cleanse.cpp. 2. The value wasn't forwarded to libsecp as a user might have reasonably expected. 3. We now have the DISABLE_OPTIMIZED_SHA256 define which is what disable-asm actually did in practice. If there is any desire, we can hook DISABLE_OPTIMIZED_SHA256 up to a new configure option that actually does what it says.
2024-02-28Merge bitcoin/bitcoin#29484: serialization: replace char-is-int8_t autoconf ↵fanquake
detection with c++20 concept ad7584d8b60119ca3717117a1eb6a16d753c5d74 serialization: replace char-is-int8_t autoconf detection with c++20 concept (Cory Fields) Pull request description: Doesn't depend on #29263, but it's really only relevant after that one's merged. This removes the only remaining autoconf macro in our serialization code (after #29263), so it can now be used trivially and safely out-of-tree. ~Our code does not currently contain any concepts, but couldn't find any discussion or docs about avoiding them. I guess we'll see if this blows up our c-i.~ Edit: Ignore this. ajtowns pointed out that we're already using a few concepts. This was introduced in #13580. Please check my logic on this as I'm unable to test on a SmartOS system. Even better would be a confirmation from someone who can build there. ACKs for top commit: Empact: Code review ACK https://github.com/bitcoin/bitcoin/commit/ad7584d8b60119ca3717117a1eb6a16d753c5d74 Tree-SHA512: 1faf65c900700efb1cf3092c607a2230321b393cb2f029fbfb94bc8e50df1dabd7a9e4b91e3b34f0d2f3471aaf18ee7e56d91869db5c5f4bae84da95443e1120
2024-02-28serialization: use internal endian conversion functionsCory Fields
These replace our platform-specific mess in favor of c++20 endian detection via std::endian and internal byteswap functions when necessary. They no longer rely on autoconf detection.
2024-02-28serialization: detect byteswap builtins without autoconf testsCory Fields
Rather than a complicated set of tests to decide which bswap functions to use, always prefer the compiler built-ins when available. These builtins and fallbacks can all be removed once we're using c++23, which adds std::byteswap.
2024-02-27serialization: replace char-is-int8_t autoconf detection with c++20 conceptCory Fields
This removes the only remaining autoconf macro in our serialization code, so it can now be used trivially and safely out-of-tree.
2024-02-27build: remove -Wdocumentation conditionalfanquake
Now that --enable-suppress-external-warnings is on by default, we can drop it.
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`.
generated by cgit v1.2.3 (git 2.26.2) at 2024-10-30 09:21:15 +0000