aboutsummaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2021-12-03build: remove x-prefix comparisonsfanquake
Very old shells suffered from bugs which meant that prefixing variables with an "x" to ensure that the lefthand side of a comparison always started with an alphanumeric character was needed. Modern shells don't suffer from this issue (i.e Bash was fixed in 1996). In any case, we've already got unprefixed checks used in our codebase, i.e https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L292, and have dependencies (in depends) that also use unprefixed comparisons. I think it's time that we can consolidate on not using the x-prefix workaround. At best it's mostly just confusing. More info: https://github.com/koalaman/shellcheck/wiki/SC2268 https://www.vidarholen.net/contents/blog/?p=1035
2021-11-25Merge bitcoin/bitcoin#23152: build: add `--enable-lto` configuration optionfanquake
68e5aafde3e87c16da95410a0474f38f589afb36 build: add `--enable-lto` configuration option (fanquake) Pull request description: It's been 5 years since using LTO was first suggested for use when building Bitcoin Core, and it's time to revisit it again. Compilers, and their LTO implementations, have matured, and Bitcoin Core has come a long way in terms of pruning dependencies which may have proved troublesome (i.e Boost previously had issues when using LTO). We'll have even less Boost code after moving to `std::filesystem` (#20744). Experimenting with LTO came up on IRC last night: > sipa: jamesob: i'm interested in knowing whether "-flto" and/or "-fdata-sections -ffunction-sections -Wl,--gc-sections" are possible/beneficial with our current compiler suite; what would be a good way to have your test infrastructure benchmark things? So this PR just adds the bare minimum to make it easier to configure, compile and perform some bench-marking using `-flto`. This PR doesn't do anything depends wise, however if we decide this is what we want to do, I'll expand the changes here. I had previously had a PR open (#18605) to perform link time garbage collection (`-ffunction-sections -fdata-sections` & `-Wl,--gc-sections`), however moving straight to using LTO would be preferable. Note that our minimum required set of compilers, GCC 8.1 and Clang 7, all support the `-flto` option. Related #18579. Previous discussion: #10616, #14277. Previous related PRs: #10800 (`-flto`), #16791 (ThinLTO). Guix build: ```bash bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum 1f3a7c5be4169aaa444b481d3e65a7bb72da9007fee6e6c416ded2e70f97374b guix-build-68e5aafde3e8/output/aarch64-linux-gnu/SHA256SUMS.part fa8f4cf223d9aaf0b2c1ef55ce61256a19cd1ad7f42b99d0b98c9a52fe6ad8ba guix-build-68e5aafde3e8/output/aarch64-linux-gnu/bitcoin-68e5aafde3e8-aarch64-linux-gnu-debug.tar.gz 9a9967078cd1849b4e85db619e1f55d305c6d44e9e013067c0e8d62c1ba54087 guix-build-68e5aafde3e8/output/aarch64-linux-gnu/bitcoin-68e5aafde3e8-aarch64-linux-gnu.tar.gz 18c71f30722102baaf3dfda67f7c7aac38723510b142e8df8ee7063c5d499368 guix-build-68e5aafde3e8/output/arm-linux-gnueabihf/SHA256SUMS.part 0854cc0d17c045a118df2a24e4cf36d727e7e7e2dea37c2492ee21b71cb79b4b guix-build-68e5aafde3e8/output/arm-linux-gnueabihf/bitcoin-68e5aafde3e8-arm-linux-gnueabihf-debug.tar.gz 215256897dde4e8412ed60473376c694a80c5479fb08039107fb62435f2816ef guix-build-68e5aafde3e8/output/arm-linux-gnueabihf/bitcoin-68e5aafde3e8-arm-linux-gnueabihf.tar.gz 5fad0d9d12bc514ec46ed5d66fd29b7da1376a4a69c3b692936f1ab2356e2f85 guix-build-68e5aafde3e8/output/dist-archive/bitcoin-68e5aafde3e8.tar.gz 4f32989d4ab1946048ca7caee9a983fa875be262282562f5a3e040f4bf92158e guix-build-68e5aafde3e8/output/powerpc64-linux-gnu/SHA256SUMS.part ae45df309ae8ada52891efac0a369a69fed4ab93847a7bc4150a62230df4c8d7 guix-build-68e5aafde3e8/output/powerpc64-linux-gnu/bitcoin-68e5aafde3e8-powerpc64-linux-gnu-debug.tar.gz 0ced227de15cb578567131271e2effe80681b4d7a436c92bf1caec735a576fa4 guix-build-68e5aafde3e8/output/powerpc64-linux-gnu/bitcoin-68e5aafde3e8-powerpc64-linux-gnu.tar.gz 26fc5d2ccc1bc17ee0a146cacada6f4909d90c136ae640c8337332adce414ee0 guix-build-68e5aafde3e8/output/powerpc64le-linux-gnu/SHA256SUMS.part 9956b544d90a62a8ba9fc9dc6b6b7f0efe193357332ec19e88053a89d4aab37e guix-build-68e5aafde3e8/output/powerpc64le-linux-gnu/bitcoin-68e5aafde3e8-powerpc64le-linux-gnu-debug.tar.gz be8e39ceea1d36086ce5fa93bfb138c68d3bdf0dd6950b192dfa27a65cce3836 guix-build-68e5aafde3e8/output/powerpc64le-linux-gnu/bitcoin-68e5aafde3e8-powerpc64le-linux-gnu.tar.gz a7755edc394972885c4c77a7798007e5ba4126b177c4ff6224275c4fb8f3b1c4 guix-build-68e5aafde3e8/output/riscv64-linux-gnu/SHA256SUMS.part b6d252993d8aae7582ad6385fe53c61c54c284c68ece6cb2b2d1ac9554e06139 guix-build-68e5aafde3e8/output/riscv64-linux-gnu/bitcoin-68e5aafde3e8-riscv64-linux-gnu-debug.tar.gz bb4860f3bbd815f800333124ff901d880741792ab47097f49bda3a6931144da0 guix-build-68e5aafde3e8/output/riscv64-linux-gnu/bitcoin-68e5aafde3e8-riscv64-linux-gnu.tar.gz 3dd17deed5c5935fb28b62dfc7afca5caab0d67862cdcbf3337edae73e1d0c4c guix-build-68e5aafde3e8/output/x86_64-apple-darwin19/SHA256SUMS.part fa2d68c54fda0816188c81ce2201a77340b82645da2ffe412526f92c297a82df guix-build-68e5aafde3e8/output/x86_64-apple-darwin19/bitcoin-68e5aafde3e8-osx-unsigned.dmg f6e5accdcd201f522b6426e4d8cc9b3643d4d43a57d268fa0e79ea9a34cfac01 guix-build-68e5aafde3e8/output/x86_64-apple-darwin19/bitcoin-68e5aafde3e8-osx-unsigned.tar.gz 4e5a127df957d1c73b65925d685f6620e7bc5667efcb6dcd98be76effc22fc12 guix-build-68e5aafde3e8/output/x86_64-apple-darwin19/bitcoin-68e5aafde3e8-osx64.tar.gz 56ccd216a69acafacbdc6bae0bdcc1faa50b6a51be1aebfa7068206c88b3241a guix-build-68e5aafde3e8/output/x86_64-linux-gnu/SHA256SUMS.part 77b93dd5fad322636853e5b0244ffafd97cc97f3b4b4ee755d5f830b75d77d13 guix-build-68e5aafde3e8/output/x86_64-linux-gnu/bitcoin-68e5aafde3e8-x86_64-linux-gnu-debug.tar.gz 1feda932fc127b900316a232432b91e46e57ee12a81e12a7d888fdc3296219c1 guix-build-68e5aafde3e8/output/x86_64-linux-gnu/bitcoin-68e5aafde3e8-x86_64-linux-gnu.tar.gz aa7c53ab4164b3736049065c3c24391fc5bd7f26b4bda4aa877c378f0636a125 guix-build-68e5aafde3e8/output/x86_64-w64-mingw32/SHA256SUMS.part 5e76148e67aef7e91e70074bfadc08e94373449ac3b966f4343b04d230c778fd guix-build-68e5aafde3e8/output/x86_64-w64-mingw32/bitcoin-68e5aafde3e8-win-unsigned.tar.gz 34123e3d818beeb70113caeda66945bc7cb9d9e987515d5b149bd17b4b38da90 guix-build-68e5aafde3e8/output/x86_64-w64-mingw32/bitcoin-68e5aafde3e8-win64-debug.zip 2bba7f40a2b23c6ea3d47c4f564ab54201bf27f7f57103a98cc9bceea4e70c4d guix-build-68e5aafde3e8/output/x86_64-w64-mingw32/bitcoin-68e5aafde3e8-win64-setup-unsigned.exe 0e7e124144af4a92a4344cf70a3b7c06fbd2b8782aee7ede7263893afa3a5ef0 guix-build-68e5aafde3e8/output/x86_64-w64-mingw32/bitcoin-68e5aafde3e8-win64.zip ``` ACKs for top commit: laanwj: Code review ACK 68e5aafde3e87c16da95410a0474f38f589afb36 Tree-SHA512: 5c25249cc178b9d54159e268390c974b739df9458d773e23c14b14d808f87f7afe314058b3c068601a9132042321973b0c9b6f81becb925665eca2738ae9a613
2021-11-22Merge bitcoin/bitcoin#23557: configure.ac: remove BashismMarcoFalke
cf7292597e18ffca06b0fbf8bcd545aec387e380 configure.ac: remove Bashism (Matt Whitlock) Pull request description: Configure scripts are supposed to adhere to the POSIX shell language. The POSIX `test` builtin does not implement an `==` operator. Bash does, but not all systems have Bash installed as `/bin/sh`. In particular, many systems use the lighter-weight Dash as the default POSIX shell. Dash emits the following error when running `configure`: ``` ./configure: 39065: test: xno: unexpected operator ``` This PR removes the Bashism and restores correct operation with POSIX-compliant shells like Dash. ACKs for top commit: katesalazar: ACK cf7292597e18ffca06b0fbf8bcd545aec387e380. laanwj: Code review ACK cf7292597e18ffca06b0fbf8bcd545aec387e380 Tree-SHA512: 578c873fba52e0472baed9e024bddcf58a0e088600bd5854f3011f1f8d135773ad923bb16baefc960d17ecedee9cc980b36aaa70fb32eb9bc7de93f7fe60541d
2021-11-21build: don't check for deprecated qt5 packagefanquake
Use qt@5 instead.
2021-11-21build: don't check for deprecated berkeley-db4 packagefanquake
Fixes: ```bash checking for brew... brew Warning: Use berkeley-db@4 instead of deprecated berkeley-db4 ```
2021-11-19configure.ac: remove BashismMatt Whitlock
2021-11-16build: add `--enable-lto` configuration optionfanquake
Co-authored-by: Cory Fields <cory-nospam-@coryfields.com> Co-authored-by: Elichai Turkel <elichai.turkel@gmail.com>
2021-11-16build: remove D__STDC_FORMAT_MACROS from CPPFLAGSfanquake
This was used to expose additional formatting macros in glibs / std libs. However this is no-longer required now that we require glibc 2.18+. See https://sourceware.org/bugzilla/show_bug.cgi?id=15366.
2021-11-16build: require glibc 2.18+ for release buildsfanquake
From what I can see the only platform this drops support for is CentOS 7. CentOS 7 reached the end of it's "full update" support at the end of 2020. It does receive maintenance updates until 2024, however I don't think supporting glibc 2.17 until 2024 is realistic. Note that anyone wanting to self-compile and target a glibc 2.17 runtime could build with --disable-threadlocal. glibc 2.18 was released in August 2013. https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html
2021-11-13build: Drop unneeded dependencies for bitcoin-wallet toolHennadii Stepanov
2021-11-12build: consistently quote AC_CHECK_LIB() argumentsfanquake
2021-11-12build: consistently quote AC_MSG_* argumentsfanquake
2021-11-12build: consistently quote AC_CHECK_PROG() argumentsfanquake
2021-11-12build: consistently quote arguments in AC_ARG_VAR()fanquake
2021-11-12build: consistently quote arguments in AM_CONDITIONAL()fanquake
2021-11-12build: consistently quote AC_DEFINE() argumentsfanquake
2021-11-12build: consistently quote AC_MSG_CHECKING() argumentsfanquake
2021-11-12build: consistently quote AC_PATH_TOOL argumentsfanquake
2021-11-12build: AC_PATH_PROG(S) consistently quote argumentsfanquake
2021-11-12build: cleanup AX_CHECK_PREPROC_FLAG() usagefanquake
There should be no functional change.
2021-11-12build: cleanup AX_CHECK_COMPILE_FLAG() usagefanquake
There should be no functional change.
2021-11-12build: cleanup AX_CHECK_LINK_FLAG() usagefanquake
There should be no functional change.
2021-11-12Merge bitcoin/bitcoin#23114: Add minisketch subtree and integrate into ↵fanquake
build/test 29173d6c6ca0cc3be9fa6bf2409a509ffea1a02a ubsan: add minisketch exceptions (Cory Fields) 54b5e1aeab73953c1f12ec2c041572038f6f59da Add thin Minisketch wrapper to pick best implementation (Pieter Wuille) ee9dc71c1bc16205494f2a0aebe575a3c062ff52 Add basic minisketch tests (Pieter Wuille) 0659f12b131fc5915fe7a493306af197f4fb838b Add minisketch dependency (Gleb Naumenko) 0eb7928ab8d9dcb840e4965bfa81deb752b00dfa Add MSVC build configuration for libminisketch (Pieter Wuille) 8bc166d5b179205fc56855e2b462aa273a6f8661 build: add minisketch build file and include it (Cory Fields) b2904ceb85b4d440b1f4bbd716fcb601411cc2c9 build: add configure checks for minisketch (Cory Fields) b6487dc4ef47ec9ea894eceac25f37d0b806f8aa Squashed 'src/minisketch/' content from commit 89629eb2c7 (fanquake) Pull request description: This takes over #21859, which has [recently switched](https://github.com/bitcoin/bitcoin/pull/21859#issuecomment-921899200) to my integration branch. A few more build issues came up (and have been fixed) since, and after discussing with sipa it was decided I would open a PR to shepherd any final changes through. > This adds a `src/minisketch` subtree, taken from the master branch of https://github.com/sipa/minisketch, to prepare for Erlay implementation (see #21515). It gets configured for just supporting 32-bit fields (the only ones we're interested in in the context of Erlay), and some code on top is added: > * A very basic unit test (just to make sure compilation & running works; actual correctness checking is done through minisketch's own tests). > * A wrapper in `minisketchwrapper.{cpp,h}` that runs a benchmark to determine which field implementation to use. Only changes since my last update to the branch in the previous PR have been rebasing on master and fixing an issue with a header in an introduced file. ACKs for top commit: naumenkogs: ACK 29173d6c6ca0cc3be9fa6bf2409a509ffea1a02a Tree-SHA512: 1217d3228db1dd0de12c2919314e1c3626c18a416cf6291fec99d37e34fb6eec8e28d9e9fb935f8590273b8836cbadac313a15f05b4fd9f9d3024c8ce2c80d02
2021-10-22fuzz: Add wallet fuzz testMarcoFalke
2021-10-21build: add configure checks for minisketchCory Fields
AC_DEFINE'd values won't be passed down to minisketch because it does not use bitcoin-config.h. Thus we need a way to know if we should manually add defines for minisketch files.
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.
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-02 14:35:18 +0000