aboutsummaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2021-10-21Merge bitcoin/bitcoin#23282: build: remove build stubs for external leveldbfanquake
17ae2601c786e6863cee1bd62297d79521219295 build: remove build stubs for external leveldb (Cory Fields) Pull request description: Presumably these stubs indicate to packagers that external leveldb is meant to be supported in some way. It is not. Remove the stubs to avoid sending any mixed messages. For context, this was reported on IRC: > \<Talkless> bitcoind fails to start with undefined symbol: _ZTIN7leveldb6LoggerE in Debian Sid after leveldb upgraded from 1.22 to 1.23: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996486 ACKs for top commit: fanquake: ACK 17ae2601c786e6863cee1bd62297d79521219295 hebasto: ACK 17ae2601c786e6863cee1bd62297d79521219295. I have reviewed the code and it looks OK, I agree it can be merged. Tree-SHA512: 2f1ac2cb30dac64791933a245a2b66ce237bde3955e6f4a6b7ec181248f77a9b1b10597d865d3e2c2b6def696af70de40e905ec274e4ae7cccd1daf461473957
2021-10-20build: explicitly disable libsecp256k1 openssl based testsfanquake
These tests are failing when run against OpenSSL 3, and have been removed upstream, https://github.com/bitcoin-core/secp256k1/pull/983, so disabled them for now to avoid `make check` failures. Note that this will also remove warning output from our build, due to the use of deprecated OpenSSL API functions. See #23048.
2021-10-20build: fix python detection post #23182fanquake
23182 was broken. Fix up the changes, and add python3.11 as suggested.
2021-10-20Merge bitcoin/bitcoin#22646: build: tighter Univalue integration, remove ↵fanquake
`--with-system-univalue` 0f95247246344510c9a51810c14c633abb382e95 Integrate univalue into our buildsystem (Cory Fields) 9b49ed656fb2b687fbbe8a3236d18285957eee16 Squashed 'src/univalue/' changes from 98fadc0909..a44caf65fe (fanquake) Pull request description: This PR more tightly integrates building Univalue into our build system. This follows the same approach we use for [LevelDB](https://github.com/bitcoin-core/leveldb/), ([`Makefile.leveldb.include`](https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.leveldb.include)), and [CRC32C](https://github.com/bitcoin-core/crc32c) ([`Makefile.crc32c.include`](https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.crc32c.include)), and will be the same approach we use for [minisketch](https://github.com/sipa/minisketch); see #23114. This approach yields a number of benefits, including: * Faster configuration due to one less subconfigure being run during `./configure` i.e 22s with this PR vs 26s * Faster autoconf i.e 13s with this PR vs 17s * Improved caching * No more issues with compiler flags i.e https://github.com/bitcoin/bitcoin/pull/12467 * More direct control means we can build exactly the objects we want There might be one argument against making this change, which is that builders should have the option to use "proper shared/system libraries". However, I think that falls down for a few reasons. The first being that we already don't support building with a number of system libraries (secp256k1, leveldb, crc32c); some for good reason. Univalue is really the odd one out at the moment. Note that the only fork of Core I'm aware of, that actively patches in support for using system libs, also explicitly marks them as ["DANGEROUS"](https://github.com/bitcoinknots/bitcoin/blob/a886811721ce66eb586871706b3f5dd27518ac3e/configure.ac#L1430) and ["NOT SUPPORTED"](https://github.com/bitcoinknots/bitcoin/blob/a886811721ce66eb586871706b3f5dd27518ac3e/configure.ac#L1312). So it would seem they exist more to satisfy a distro requirement, as opposed to something that anyone should, or would actually use in practice. PRs like #22412 highlight the "issue" with us operating with our own Univalue fork, where we actively fix bugs, and make improvements, when upstream (https://github.com/jgarzik/univalue) may not be taking those improvements, and by all accounts, is not currently actively maintained. Bitcoin Core should not be hamstrung into not being able to fix bugs in a library, and/or have to litter our source with "workarounds", i.e #22412, for bugs we've already fixed, based on the fact that an upstream project is not actively being maintained. Allowing builders to use system libs is really only exacerbating this problem, with little benefit to our project. Bitcoin Core is not quite like your average piece of distro packaged software. There is the potential for us to give the same treatment to libsecp256k1, however it seems doing that is currently less straightforward. ACKs for top commit: dongcarl: ACK 0f95247246 less my comment above, always nice to have an include-able `sources.mk` which makes integration easier. theuni: ACK 0f95247246344510c9a51810c14c633abb382e95. Thanks fanquake for keeping this going. Tree-SHA512: a7f2e41ee7cba06ae72388638e86b264eca1b9a8b81c15d1d7b45df960c88c3b91578b4ade020f8cc61d75cf8d16914575f9a78fa4cef9c12be63504ed804b99
2021-10-15build: remove build stubs for external leveldbCory Fields
Presumably these stubs indicate to packagers that external leveldb is meant to be supported in some way. It is not. Remove the stubs to avoid sending any mixed messages.
2021-10-14Merge bitcoin/bitcoin#23269: build: remove redundant warning flagsfanquake
aa69fd6caf1b08bfc64889c91639046fb1114326 build: Drop -Wno-unused-local-typedef (Hennadii Stepanov) 672e8c5d073b5e2f1bc63095bbcd2854c6bbd2d4 build: remove -Wunused-variable (fanquake) 5239af0574243662c0f8304fc922641b1252604b build: remove -Wswitch (fanquake) 0375906e0a9d05b16b3b8e516d2ab74368e7e90a build: use loop-analysis over range-loop-analysis (fanquake) 12712fa2c4c12edf530cd630072796ff08daa4fe build: remove -Wsign-compare (fanquake) Pull request description: This remove the addition of flags that are already part of other options, such as `-Wall` or `-Wextra`; see each commit message for details. All of the flags being removed here already exist as part of `-Wall` as of GCC 8, or, for Clang, all exist in `-Wmost` (included in `-Wall)`, or as part of `-Wextra` as of Clang 7. Both of which are our minimum required compilers. Also cherry-picks one change from #21458. To give an example of how GCCs `-Wall` has changed over the last few releases: ### 11.x to trunk (12.x) Added: ```bash -Wzero-length-bounds -Wmismatched-dealloc -Wmismatched-new-delete (only for C/C++) ``` ### 10.x to 11.x Added: ```bash -Warray-parameter=2 (C and Objective-C only) -Wrange-loop-construct (only for C++) -Wsizeof-array-div -Wvla-parameter (C and Objective-C only) ``` Removed: ```bash -Wenum-conversion in C/ObjC; ``` ### 9.x to 10.x Added: ```bash -Wenum-conversion in C/ObjC; -Wformat-overflow -Wformat-truncation -Wzero-length-bounds ``` ### 8.x to 9.x Added: ```bash -Wpessimizing-move ``` Removed: ```bash -Wstringop-truncation ``` ### 7.x to 8.x Added: ```bash -Wcatch-value (C++ and Objective-C++ only) -Wmissing-attributes -Wmultistatement-macros -Wrestrict -Wsizeof-pointer-div -Wstringop-truncation ``` [Clang Warning Options](https://clang.llvm.org/docs/DiagnosticsReference.html) [GCC Warning Options](https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) ACKs for top commit: meshcollider: utACK aa69fd6caf1b08bfc64889c91639046fb1114326 Tree-SHA512: 34dde6bd773c864202c151eaa35f902d03fb531c27fe5e1ef659225da03acade2efe5df56df3efb4df5bbded3d395348ce03c25b837fce83be53af3352f0f2bc
2021-10-13Merge bitcoin/bitcoin#22392: scripts: use LIEF for ELF security & symbol checksW. J. van der Laan
ce69e18947dd917d54eb036e732ac7f7bceede76 scripts: remove pixie.py (fanquake) 00b85d0b13e419c1b48f47a90236cb4ed7fab491 scripts: only parse the binary once in security-check.py (fanquake) cad40a5b167c5300564bd7b4505cf6650780084b scripts: use LIEF for ELF checks in security-check.py (fanquake) 8242ae230e1ff362a4e16f1503e503317471c790 scripts: only parse the binary once in symbol-check.py (fanquake) 309eac9019c224dfd79a78e381cfcb70fee190f3 scripts: use LIEF for ELF checks in symbol-check.py (fanquake) 610a8a8e39c1d94839dfb7e1c66c01f13f946657 test-*-check: Pass in *FLAGS and compile with them (Carl Dong) Pull request description: This finishes the transition to using LIEF for the ELF symbol and security checks. Note that there's currently a work around used for identifying RISCV binaries (just checking the interpreter). I've sent a PR upstream, https://github.com/lief-project/LIEF/pull/562, and we should be able to drop that when using LIEF 0.12.0 and onwards. ACKs for top commit: dongcarl: Code Review ACK ce69e18947dd917d54eb036e732ac7f7bceede76 laanwj: Code review ACK ce69e18947dd917d54eb036e732ac7f7bceede76 Tree-SHA512: 911ba693cd9777ad1fc1f66dff6c4d3630a907351215380cbde5b14a4bbf5cf7eebf52eafa7e86b27deabd2d93d1b403f34aabd356b5ceaab3cc6e9941a01dd4
2021-10-13build: Drop -Wno-unused-local-typedefHennadii Stepanov
-Wunused-local-typedef(s) is covered by -Wunused in both gcc and clang. No new warnings fire when compiling.
2021-10-13build: remove -Wunused-variablefanquake
This is enabled via -Wall in GCC, and is part of -Wunused, which is included in -Wmost, which is included in -Wall in Clang.
2021-10-13build: remove -Wswitchfanquake
This is enabled by -Wall in GCC and Clang.
2021-10-13build: use loop-analysis over range-loop-analysisfanquake
To turn on all (future) loop analysis options. Note that -Wfor-loop-analysis is also part of -Wmost, which is in -Wall.
2021-10-13build: remove -Wsign-comparefanquake
This is part of -Wall in GCC and -Wextra in Clang.
2021-10-13Merge bitcoin/bitcoin#23149: build: make --enable-werror just -Werrorfanquake
38fd709fa5b7a01f149a65efdfe1a6b463477e4e build: make --enable-werror just -Werror (fanquake) Pull request description: No longer special case a set of warnings, to make up our own -Werror, just use -Werror outright. This shouldn't really have any effect on existing builders, who were already using `--enable-werror`, and is more inline with what they would expect `--enable-werror` to be, which is erroring on any/all warnings. We keep `-Wno-error=return-type` because we know that is broken when using mingw-w64. It should only be applied when cross-compiling for Windows. Similar to the change in #20544, but with (hopefully) less work-arounds, and other bundled changes. A step towards some configure "cleanups". ACKs for top commit: hebasto: ACK 38fd709fa5b7a01f149a65efdfe1a6b463477e4e (also see https://github.com/bitcoin/bitcoin/pull/23149#issuecomment-940420776), tested: MarcoFalke: Concept ACK 38fd709fa5b7a01f149a65efdfe1a6b463477e4e Tree-SHA512: 37f1857d9408442cab63e40f9280427b73e09cdf03146b19c1339d7e44abd78e93df7f270ca1da0e83b79343cd3ea915f7b9e4e347488b5bc5ceaaa7540e5926
2021-10-12scripts: use LIEF for ELF checks in symbol-check.pyfanquake
Co-authored-by: Carl Dong <contact@carldong.me>
2021-10-11Integrate univalue into our buildsystemCory Fields
This addresses issues like the one in #12467, where some of our compiler flags end up being dropped during the subconfigure of Univalue. Specifically, we're still using the compiler-default c++ version rather than forcing c++17. We can drop the need subconfigure completely in favor of a tighter build integration, where the sources are listed separately from the build recipes, so that they may be included directly by upstream projects. This is similar to the way leveldb build integration works in Core. Core benefits of this approach include: - Better caching (for ex. ccache and autoconf) - No need for a slow subconfigure - Faster autoconf - No more missing compile flags - Compile only the objects needed There are no benefits to Univalue itself that I can think of. These changes should be a no-op there, and to downstreams as well until they take advantage of the new sources.mk. This also removes the option to use an external univalue to avoid similar ABI issues with mystery binaries. Co-authored-by: fanquake <fanquake@gmail.com>
2021-10-11Merge bitcoin/bitcoin#22409: configure: keep relative paths in debug infofanquake
0bc666b053b8f4883c3f5de43959e2bbd91b95c5 doc: add info for debugging with relative paths (S3RK) a8b515c317f0b5560f62c72a8f4eb6560d8f1c75 configure: keep relative paths in debug info (S3RK) Pull request description: This is a follow-up for #20353 that fixes #21885 It also adds a small section to assist debugging without absolute paths in debug info. ACKs for top commit: kallewoof: Tested ACK 0bc666b053b8f4883c3f5de43959e2bbd91b95c5 Zero-1729: Light crACK 0bc666b053b8f4883c3f5de43959e2bbd91b95c5 Tree-SHA512: d4b75183c3d3a0f59fe786841fb230581de87f6fe04cf7224e4b89c520d45513ba729d4ad8c0e62dd1dbaaa7a25741f04d036bc047f92842e76c9cc31ea47fb2
2021-10-05build: add python3.10 alias to AC_PATH_PROGS call in configurefanquake
Python 3.10 is now relased, and has been available as a beta/rc in distros for a little while already.
2021-10-04Merge bitcoin/bitcoin#20487: Add syscall sandboxing using seccomp-bpf (Linux ↵W. J. van der Laan
secure computing mode) 4747da3a5b639b5a336b737e7e3cbf060cf2efcf Add syscall sandboxing (seccomp-bpf) (practicalswift) Pull request description: Add experimental syscall sandboxing using seccomp-bpf (Linux secure computing mode). Enable filtering of system calls using seccomp-bpf: allow only explicitly allowlisted (expected) syscalls to be called. The syscall sandboxing implemented in this PR is an experimental feature currently available only under Linux x86-64. To enable the experimental syscall sandbox the `-sandbox=<mode>` option must be passed to `bitcoind`: ``` -sandbox=<mode> Use the experimental syscall sandbox in the specified mode (-sandbox=log-and-abort or -sandbox=abort). Allow only expected syscalls to be used by bitcoind. Note that this is an experimental new feature that may cause bitcoind to exit or crash unexpectedly: use with caution. In the "log-and-abort" mode the invocation of an unexpected syscall results in a debug handler being invoked which will log the incident and terminate the program (without executing the unexpected syscall). In the "abort" mode the invocation of an unexpected syscall results in the entire process being killed immediately by the kernel without executing the unexpected syscall. ``` The allowed syscalls are defined on a per thread basis. I've used this feature since summer 2020 and I find it to be a helpful testing/debugging addition which makes it much easier to reason about the actual capabilities required of each type of thread in Bitcoin Core. --- Quick start guide: ``` $ ./configure $ src/bitcoind -regtest -debug=util -sandbox=log-and-abort … 2021-06-09T12:34:56Z Experimental syscall sandbox enabled (-sandbox=log-and-abort): bitcoind will terminate if an unexpected (not allowlisted) syscall is invoked. … 2021-06-09T12:34:56Z Syscall filter installed for thread "addcon" 2021-06-09T12:34:56Z Syscall filter installed for thread "dnsseed" 2021-06-09T12:34:56Z Syscall filter installed for thread "net" 2021-06-09T12:34:56Z Syscall filter installed for thread "msghand" 2021-06-09T12:34:56Z Syscall filter installed for thread "opencon" 2021-06-09T12:34:56Z Syscall filter installed for thread "init" … # A simulated execve call to show the sandbox in action: 2021-06-09T12:34:56Z ERROR: The syscall "execve" (syscall number 59) is not allowed by the syscall sandbox in thread "msghand". Please report. … Aborted (core dumped) $ ``` --- [About seccomp and seccomp-bpf](https://en.wikipedia.org/wiki/Seccomp): > In computer security, seccomp (short for secure computing mode) is a facility in the Linux kernel. seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), and read() and write() to already-open file descriptors. Should it attempt any other system calls, the kernel will terminate the process with SIGKILL or SIGSYS. In this sense, it does not virtualize the system's resources but isolates the process from them entirely. > > […] > > seccomp-bpf is an extension to seccomp that allows filtering of system calls using a configurable policy implemented using Berkeley Packet Filter rules. It is used by OpenSSH and vsftpd as well as the Google Chrome/Chromium web browsers on Chrome OS and Linux. (In this regard seccomp-bpf achieves similar functionality, but with more flexibility and higher performance, to the older systrace—which seems to be no longer supported for Linux.) ACKs for top commit: laanwj: Code review and lightly tested ACK 4747da3a5b639b5a336b737e7e3cbf060cf2efcf Tree-SHA512: e1c28e323eb4409a46157b7cc0fc29a057ba58d1ee2de268962e2ade28ebd4421b5c2536c64a3af6e9bd3f54016600fec88d016adb49864b63edea51ad838e17
2021-10-01Add syscall sandboxing (seccomp-bpf)practicalswift
2021-10-01build: make --enable-werror just -Werrorfanquake
No longer special case a set of warnings, to make up our own -Werror, just use -Werror outright. This shouldn't really have any effect on existing builders, who were already using --enable-werror, and is more inline with what they would expect --enable-werror to be, which is erroring on any/all warnings. We keep -Wno-error=return-type because we know that is broken when using mingw-w64. It should only be applied when cross-compiling for Windows. Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
2021-09-24build: remove support for weak linking getauxval()fanquake
It was [pointed out in #23030](https://github.com/bitcoin/bitcoin/pull/23030#issuecomment-922893367) that we might be able to get rid of our weak linking of [`getauxval()`](https://man7.org/linux/man-pages/man3/getauxval.3.html) (`HAVE_WEAK_GETAUXVAL`) entirely, with only Android being a potential holdout: > I wonder if it's time to get rid of HAVE_WEAK_GETAUXVAL. I think it's confusing. Either we build against a C library that has this functionality, or not. We don't do this weak linking thing for any other symbols and recently got rid of the other glibc backwards compatibility stuff. > Unless there is still a current platform that really needs it (Android?), I'd prefer to remove it from the build system, it has caused enough issues. After looking at Android further, it would seem that given we are moving to using `std::filesystem`, which [requires NDK version 22 and later](https://github.com/android/ndk/wiki/Changelog-r22), and `getauxval` has been available in the since [API version 18](https://developer.android.com/ndk/guides/cpu-features#features_using_libcs_getauxval3), that shouldn't really be an issue. Support for API levels < 19 will be dropped with the NDK 24 release, and according to [one website](https://apilevels.com/), supporting API level 18+ will cover ~99% of devices. Note that in the CI we currently build with NDK version 22 and API level 28. The other change in this PR is removing the include of headers for ARM intrinsics, from the check for strong `getauxval()` support in configure, as they shouldn't be needed. Including these headers also meant that the check would basically only succeed when building for ARM. This would be an issue if we remove weak linking, as we wouldn't detect `getauxval()` as supported on other platforms. Note that we also use `getauxval()` in our RNG when it's available. I've checked that with these changes we detect support for strong `getauxval()` on Alpine (muslibc). On Linux, previously we'd be detecting support for weak getauxval(), now we detect strong support. Note that we already require glibc 2.17, and `getauxval()` was introduced in `2.16`. This is an alternative / supersedes #23030.
2021-09-24build: remove arm includes from getauxval() checkfanquake
Then the check will work on platforms other than ARM.
2021-09-21build: Restrict check for CRC32C intrinsic to aarch64W. J. van der Laan
`crc32c`'s hardware accelerated code doesn't handle ARM 32-bit at all. Make the check in `configure.ac` check for this architecture explicitly. For the release binaries, the current `configure.ac` check happens to work: it enables it on aarch64 but disables it for armhf. However some combination of compiler version and settings might ostensibly cause this check to succeed on armhf (as reported on IRC). So make the 64-bit platform requirement explicit.
2021-09-16Merge bitcoin/bitcoin#22845: build: improve check for ::(w)systemW. J. van der Laan
3ec633ef1a99d3a71c19ab5563a82bc275659d2e build: improve check for ::(w)system (fanquake) Pull request description: `AC_DEFINE()` takes `HAVE_STD__SYSTEM || HAVE_WSYSTEM` literally, meaning you end up with the following in bitcoin-config.h: ```cpp /* std::system or ::wsystem */ #define HAVE_SYSTEM HAVE_STD__SYSTEM || HAVE_WSYSTEM ``` This works for the preprocessor, because `HAVE_SYSTEM`, is defined, just unusually. Remove this in favor of setting `have_any_system` in either case, given we don't actually use `HAVE_STD__SYSTEM` or `HAVE_WSYSTEM`, and defining `HAVE_SYSTEM` to 1 thereafter. ACKs for top commit: laanwj: Code review ACK 3ec633ef1a99d3a71c19ab5563a82bc275659d2e Tree-SHA512: 02c39ba3179136ec1dc28df026b7fa5d732914c85622298ba7ec880f1ae9324208d322a47be451a5c2ff2e165ad1d446bae92e7018db8e517e7ac38fca25a0a3
2021-09-10build: remove glibc-back-compat from build systemfanquake
At this point, or minimum required glibc is implicitly 2.18, due to thread_local support being enabled by default. However, users can disable thread_local support to maintain 2.17 ccompat for now, which is currently done in the Guix build.
2021-09-10build: improve check for ::(w)systemfanquake
`AC_DEFINE()` takes `HAVE_STD__SYSTEM || HAVE_WSYSTEM` literally, meaning you end up with the following in bitcoin-config.h: ```cpp /* std::system or ::wsystem */ #define HAVE_SYSTEM HAVE_STD__SYSTEM || HAVE_WSYSTEM ``` This works for the preprocessor, because `HAVE_SYSTEM`, is defined, just unusually. Remove this in favor of defining `HAVE_SYSTEM` to 1 in either case, given we don't actually use `HAVE_STD__SYSTEM` or `HAVE_WSYSTEM`. We just use ::system if we aren't building for Windows.
2021-09-06Merge bitcoin/bitcoin#22397: build: Fix macOS Apple Silicon build with ↵W. J. van der Laan
miniupnpc and libnatpmp 2445df4eb36ba0d90e1283f36e629e1cf69eeef7 build: Fix macOS Apple Silicon build with miniupnpc and libnatpmp (Hennadii Stepanov) Pull request description: On master (7a49fdc58115845ece3a9890bf9498bee6b559de) the `configure` script does not pick up Homebrew's `miniupnpc` and `libnatpmp` packages on macOS Apple Silicon: ``` % ./configure --with-miniupnpc ... checking for miniupnpc/miniupnpc.h... no checking for miniupnpc/upnpcommands.h... no checking for miniupnpc/upnperrors.h... no ... checking whether to build with support for UPnP... configure: error: "UPnP requested but cannot be built. Use --without-miniupnpc." ``` ``` % ./configure --with-natpmp ... checking for natpmp.h... no ... checking whether to build with support for NAT-PMP... configure: error: NAT-PMP requested but cannot be built. Use --without-natpmp ``` The preferred Homebrew [prefix for Apple Silicon](https://docs.brew.sh/Installation) is `/opt/homebrew`. Therefore, if we do not use `pkg-config` to detect packages, we should set the `CPPFLAGS` and `LDFLAGS` variables for them explicitly. ACKs for top commit: Zero-1729: re-tACK 2445df4eb36ba0d90e1283f36e629e1cf69eeef7 (re-tested on an M1 Machine running macOS 11.4). jarolrod: re-ACK 2445df4eb36ba0d90e1283f36e629e1cf69eeef7 Tree-SHA512: d623d26492f463812bf66ca519847ff4b23d517466b6c51c3caf3642a582d02e5f03ce57915742b29f01bf9bceb731a3978ef9a5fdc82e568bcb62548eda758a
2021-09-02test: Rename bitcoin-util-test.py to util/test_runner.pyMarcoFalke
To normalize the name of all three test runners (fuzz, functional, util).
2021-08-27Merge bitcoin/bitcoin#20586: Fix Windows build with --enable-werrorW. J. van der Laan
b367745cfe19f6de3f44b3adc90fa08e36e44bb6 ci: Make Cirrus CI Windows build with --enable-werror (Hennadii Stepanov) c713bb2b243881a771ab288340ffeb623c82d7f6 Fix Windows build with --enable-werror on Ubuntu Focal (Hennadii Stepanov) Pull request description: This PR makes possible to cross-compile Windows build with `--enable-werror --enable-suppress-external-warnings`. Some problems are fixed, others are silenced. Also `--enable-werror` is enabled for Cirrus CI Windows build (the last one on Cirrus CI without `--enable-werror`). ACKs for top commit: practicalswift: cr ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6: patch looks correct laanwj: Code review ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6 vasild: ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6 jarolrod: ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6 Tree-SHA512: 64f5c99b7dad4c0efce80cd45d7074f275bd8411235dc9e0841287bdab64b812c6f8f9d632c35531d0b8210148531f53aaaac77be7699b29d2d6aaae304dbee0
2021-07-29build: Fix macOS Apple Silicon build with miniupnpc and libnatpmpHennadii Stepanov
The preferred Homebrew prefix for Apple Silicon is /opt/homebrew. Therefore, if we do not use pkg-config to detect packages, we should set the CPPFLAGS and LDFLAGS variables for them explicitly.
2021-07-29Merge bitcoin/bitcoin#21882: build: Fix undefined reference to __mulodi4fanquake
e4c8bb62e4a6873c45f42d0d2a24927cb241a0ea build: Fix undefined reference to __mulodi4 (Hennadii Stepanov) Pull request description: When compiling with clang on 32-bit systems the `__mulodi4` symbol is defined in compiler-rt only. Fixes #21294. See more: - https://bugs.llvm.org/show_bug.cgi?id=16404 - https://bugs.llvm.org/show_bug.cgi?id=28629 ACKs for top commit: MarcoFalke: tested-only ACK e4c8bb62e4a6873c45f42d0d2a24927cb241a0ea luke-jr: utACK e4c8bb62e4a6873c45f42d0d2a24927cb241a0ea fanquake: ACK e4c8bb62e4a6873c45f42d0d2a24927cb241a0ea - it's a bit of an awkward workaround to carry, but at-least it's contained to the fuzzers. Tree-SHA512: 93edb4ed568027702b1b9aba953ad50889b834ef97fde3cb99d1ce70076d9c00aa13f95c86b12d6f59b24fa90108d93742f920e15119901a2848fb337ab859a1
2021-07-27build: Fix undefined reference to __mulodi4Hennadii Stepanov
When compiling with clang on 32-bit systems the __mulodi4 symbol is defined in compiler-rt only.
2021-07-20build: Bump master version to 22.99.0W. J. van der Laan
Tree-SHA512: fcd9ab71dba1fc814980c144a76288c313f42a0123a6a2f44a4adc13b83b74f9fb4f029c5cd646d3c1a2bb28899e95e9fbf55cfd98b665a653624291dc9baf49
2021-07-18Merge bitcoin/bitcoin#21430: build: Add -Werror=implicit-fallthrough compile ↵fanquake
flag 3c4c8e79baf02af97ba1502189f649b04ef2198d build: Add -Werror=implicit-fallthrough compile flag (Hennadii Stepanov) 014110c47d94ece6e3e655cdbf02ed8c91c7a5cf Use C++17 [[fallthrough]] attribute, and drop -Wno-implicit-fallthrough (Hennadii Stepanov) Pull request description: ACKs for top commit: fanquake: ACK 3c4c8e79baf02af97ba1502189f649b04ef2198d - looks ok to me now. Checked that warnings occur in our code & leveldb by removing a `[[fallthrough]]` or `FALLTHROUGH_INTENDED`. jarolrod: ACK 3c4c8e79baf02af97ba1502189f649b04ef2198d theStack: ACK 3c4c8e79baf02af97ba1502189f649b04ef2198d Tree-SHA512: 4dce91f0f26b8a3de09bd92bb3d7e1995e078e3a8b3ff861c4fbf6c0b32b2327d063633b07b89c4aa94a1141d7f78d46d9d43ab8df865273e342693ad30645b6
2021-07-07build: Use and test PE binutils with --reloc-sectionCarl Dong
Also fix test-security-check.py to account for new PE PIE failure indication.
2021-07-06configure: keep relative paths in debug infoS3RK
Revert to the state prior to e507acbe and allow debugging from project root dir with `gdb src/bitcoind`.
2021-07-05build: remove --enable-determinism configure optionfanquake
2021-07-05build: Add -Werror=implicit-fallthrough compile flagHennadii Stepanov
2021-07-05Use C++17 [[fallthrough]] attribute, and drop -Wno-implicit-fallthroughHennadii Stepanov
2021-06-23build: remove check for Boost Process headerfanquake
Now that we require Boost 1.64.0+, Boost Process will be available.
2021-06-23build: remove workaround for Boost and std::atomicfanquake
2021-06-23build: set minimum required Boost to 1.64.0fanquake
2021-06-18Merge bitcoin/bitcoin#22238: build: improve detection of eBPF supportfanquake
8f7704d0321a71c1691837a6bd3b4e05f84d3031 build: improve detection of eBPF support (fanquake) Pull request description: Just checking for the `sys/sdt.h` header isn't enough, as systems like macOS have the header, but it doesn't actually have the `DTRACE_PROBE*` probes, which leads to [compile failures](https://github.com/bitcoin/bitcoin/pull/22006#issuecomment-859559004). The contents of `sys/sdt.h` in the macOS SDK is: ```bash #ifndef _SYS_SDT_H #define _SYS_SDT_H /* * This is a wrapper header that wraps the mach visible sdt.h header so that * the header file ends up visible where software expects it to be. We also * do the C/C++ symbol wrapping here, since Mach headers are technically C * interfaces. * * Note: The process of adding USDT probes to code is slightly different * than documented in the "Solaris Dynamic Tracing Guide". * The DTRACE_PROBE*() macros are not supported on Mac OS X -- instead see * "BUILDING CODE CONTAINING USDT PROBES" in the dtrace(1) manpage * */ #include <sys/cdefs.h> __BEGIN_DECLS #include <mach/sdt.h> __END_DECLS #endif /* _SYS_SDT_H */ ``` The `BUILDING CODE CONTAINING USDT PROBES` section from the dtrace manpage is available [here](https://gist.github.com/fanquake/e56c9866d53b326646d04ab43a8df9e2), and outlines the more involved process of using USDT probes on macOS. ACKs for top commit: jb55: utACK 8f7704d0321a71c1691837a6bd3b4e05f84d3031 practicalswift: cr ACK 8f7704d0321a71c1691837a6bd3b4e05f84d3031 hebasto: ACK 8f7704d0321a71c1691837a6bd3b4e05f84d3031, tested on macOS Big Sur 11.4 (20F71) and on Linux Mint 20.1 (x86_64) with depends. Tree-SHA512: 5f1351d0ac2e655fccb22a5454f415906404fdaa336fd89b54ef49ca50a442c44ab92d063cba3f161cb8ea0679c92ae3cd6cfbbcb19728cac21116247a017df5
2021-06-17Merge bitcoin/bitcoin#21935: Enable external signer support by default, ↵fanquake
reduce #ifdef 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd gui: misc external signer fixes and translation hints (Sjors Provoost) d672404466204444a1d9f2d3498de4448f53d2be refactor: make ExternalSigner NetworkArg() and m_chain private (Sjors Provoost) 4455145e266450397b45acd7286686966edd072b refactor: reduce #ifdef ENABLE_EXTERNAL_SIGNER usage (Sjors Provoost) 5be90c907eba0a38019c7d9826623d5d5f567c66 build: enable external signer by default (Sjors Provoost) 7d9453041b827bafbdfc1ac0b01c7b7e1ee2bd4f refactor: clean up external_signer.h includes (Sjors Provoost) fc0eca31b33f87882e2aa329a3746d4e08af1985 fuzz: fix fuzz binary linking order (Sjors Provoost) Pull request description: This follows the introduction of GUI support in https://github.com/bitcoin-core/gui/pull/4 I don't think we should expect GUI users to self compile. This also enables external signer support by default for RPC users. In addition this PR reduces the number of `#ifdef ENABLE_EXTERNAL_SIGNER`, which also fixes #21919. When compiled with `--disable-external-signer` such wallets can't be created in RPC or GUI, but they can be loaded. Attempting any action that calls HWI will trigger an error. Side-note: this PR may or may not (currently) break CI for the GUI repository, as explained here: https://github.com/bitcoin-core/gui/pull/4#issuecomment-769859001 ACKs for top commit: achow101: ACK 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd hebasto: re-ACK 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd Tree-SHA512: 1b71c5a8bea2be077ee9fa33a01130c957a0cf90951d4b7b04d3d0ef826bb77e474c3963abddfef2e2c1ea99d9c72cd2302d1eb9b5fcb7ba0bd2a625f006aa05
2021-06-16build: Disable deprecated-copy warning only when external warnings are enabledMarcoFalke
2021-06-16build: enable external signer by defaultSjors Provoost
2021-06-16build: improve detection of eBPF supportfanquake
Just checking for the `sys/sdt.h` header isn't enough, as systems like macOS have the header, but it doesn't actually have the dtrace probes, which leads to compile failures.
2021-06-07Merge bitcoin/bitcoin#21573: Update libsecp256k1 subtree to latest masterW. J. van der Laan
5c7ee1b2da6bf783d27034fca9dfd3a64ed525cb libsecp256k1 no longer has --with-bignum= configure option (Pieter Wuille) bdca9bcb6c9379707d09c63f02326884befbefb2 Squashed 'src/secp256k1/' changes from 3967d96bf1..efad3506a8 (Pieter Wuille) cabb5661234f8d832dbc3b65bf80b0acc02db0a0 Disable certain false positive warnings for libsecp256k1 msvc build (Pieter Wuille) Pull request description: This updates our src/secp256k1 subtree to the latest upstream master. The changes include: * The introduction of safegcd-based modular inverses, reducing ECDSA signing time by 25%-30% and ECDSA verification time by 15%-17%. * [Original paper](https://gcd.cr.yp.to/papers.html) by Daniel J. Bernstein and Bo-Yin Yang * [Implementation](https://github.com/bitcoin-core/secp256k1/pull/767) by Peter Dettman; [final](https://github.com/bitcoin-core/secp256k1/pull/831) version * [Explanation](https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md) of the algorithm using Python snippets * [Analysis](https://github.com/sipa/safegcd-bounds) of the maximum number of iterations the algorithm needs * [Formal proof in Coq](https://medium.com/blockstream/a-formal-proof-of-safegcd-bounds-695e1735a348) by Russell O'Connor, for a high-level equivalent algorithm * Removal of libgmp as an (optional) dependency (which wasn't used in the Bitcoin Core build) * CI changes (Travis -> Cirrus) * Build system improvements ACKs for top commit: laanwj: Tested ACK 5c7ee1b2da6bf783d27034fca9dfd3a64ed525cb Tree-SHA512: ad8ac3746264d279556a4aa7efdde3733e114fdba8856dd53218588521f04d83950366f5c1ea8fd56329b4c7fe08eedf8e206f8f26dbe3f0f81852e138655431
2021-05-25Merge bitcoin/bitcoin#21788: build: Silence [-Wunused-command-line-argument] ↵fanquake
warnings e9f948c72790136656df6056fd9e3698f360e077 build: Convert warnings into errors when testing for -fstack-clash-protection (Hennadii Stepanov) Pull request description: Apple clang version 12.0.5 (clang-1205.0.22.9) that is a part of Xcode 12.5, and is based on LLVM clang 11.1.0, fires spammy warnings: ``` clang: warning: argument unused during compilation: '-fstack-clash-protection' [-Wunused-command-line-argument] ``` From the https://github.com/apple/llvm-project: ``` $ git log --oneline | grep 'stack-clash-protection' 00065d5cbd02 Revert "-fstack-clash-protection: Return an actual error when used on unsupported OS" 4d59c8fdb955 -fstack-clash-protection: Return an actual error when used on unsupported OS df3bfaa39071 [Driver] Change -fnostack-clash-protection to -fno-stack-clash-protection 68e07da3e5d5 [clang][PowerPC] Enable -fstack-clash-protection option for ppc64 515bfc66eace [SystemZ] Implement -fstack-clash-protection e67cbac81211 Support -fstack-clash-protection for x86 454621160066 Revert "Support -fstack-clash-protection for x86" 0fd51a4554f5 Support -fstack-clash-protection for x86 658495e6ecd4 Revert "Support -fstack-clash-protection for x86" e229017732bc Support -fstack-clash-protection for x86 b03c3d8c6209 Revert "Support -fstack-clash-protection for x86" 4a1a0690ad68 Support -fstack-clash-protection for x86 f6d98429fcdb Revert "Support -fstack-clash-protection for x86" 39f50da2a357 Support -fstack-clash-protection for x86 ``` I suppose, that Apple clang-1205.0.22.9 ends with on of the "Revert..." commits. This PR prevents using of the `-fstack-clash-protection` flag if it causes warnings. --- System: macOS Big Sur 11.3 (20E232). ACKs for top commit: jarolrod: re-ACK e9f948c72790136656df6056fd9e3698f360e077 Sjors: tACK e9f948c72790136656df6056fd9e3698f360e077 on macOS 11.3.1 Tree-SHA512: 30186da67f9b0f34418014860c766c2e7f622405520f1cbbc1095d4aa4038b0a86014d76076f318a4b1b09170a96d8167c21d7f53a760e26017f486e1a7d39d4
2021-05-24build: Convert warnings into errors when testing for -fstack-clash-protectionHennadii Stepanov
When building with Clang, if `-fstack-clash-protection` is used with an unsupported target, it may result in hundreds of `-Wunused-command-line-argument` warnings at compile time. This is currently the case when building for at least Darwin using Apple or LLVM Clang. Unsupported targets may also include *BSD, however that is changing; see further discussion in https://reviews.llvm.org/D92245 and https://reviews.freebsd.org/D27366. Note that this option is already skipped for Windows.
generated by cgit v1.2.3 (git 2.26.2) at 2024-08-20 13:13:31 +0000