e9440aeb5cad98fea9971f5126461e0a2b30ab54 build: use __SIZEOF_INT128__ for checking __int128 availability (fanquake)
Pull request description:
We already use this in the blockfilter code,
bf66e258a8/src/blockfilter.cpp (L34-L36)
so not sure we need to maintain two different ways of testing
for the same functionality. Consolidate on testing for `__SIZEOF_INT128__`,
which we already use, is supported by the compilers we care about, and is
also used by libsecp256k1.
ACKs for top commit:
sipa:
utACK e9440aeb5cad98fea9971f5126461e0a2b30ab54
Zero-1729:
crACK e9440aeb5cad98fea9971f5126461e0a2b30ab54
Tree-SHA512: 8aeef1734486a863b5091123bb5f9ba8868b1e2b4b35114586e3eb5862a38d4a1518ed069f37f41cb5e5ce2f6c87d95671996366d5ee990e0c90f268a8978ba3
8f7b93047581c67f2133cdb8c7845471de66c30f Drop the leading 0 from the version number (Andrew Chow)
Pull request description:
Removes the leading 0 from the version number. The minor version, which we had been using as the major version, is now the major version. The revision, which we had been using as the minor version, is now the minor version. The revision number is dropped. The build number is promoted to being part of the version number. This also avoids issues where it was accidentally not included in the version number.
The CLIENT_VERSION remains the same format as previous as previously, as the Major version was 0 so it never actually got included in it.
The user agent string formatter is updated to follow this new versioning.
***
Honestly I'm just tired of all of the people asking for "1.0" that maybe this'll shut them up. Skip the whole 1.0 thing and go straight to version 22.0!
Also, this means that the terminology we commonly use lines up with how the variables are named. So major versions are actually bumping the major version number, etc.
ACKs for top commit:
jnewbery:
Code review ACK 8f7b930475
MarcoFalke:
review ACK 8f7b93047581c67f2133cdb8c7845471de66c30f 🎻
Tree-SHA512: b5c3fae14d4c0a9c0ab3b1db7c949ecc0ac3537646306b13d98dd0efc17c489cdd16d43f0a24aaa28e9c4a92ea360500e05480a335b03f9fb308010cdd93a436
253f5929097548fb10ef995002dedbb8dadb6a0d Add stdin, stdout, stderr to ignored export list (Chun Kuan Lee)
fc6a9f2ab18ca8466d65d14c263c4f78f9ccebbf Use IN6ADDR_ANY_INIT instead of in6addr_any (Cory Fields)
908c1d7745f0ed117b0374fcc8486f83bf743bfc GCC-7 and glibc-2.27 compat code (Chun Kuan Lee)
Pull request description:
The `__divmoddi4` code was modified from https://github.com/gcc-mirror/gcc/blob/master/libgcc/libgcc2.c . I manually find the older glibc version of log2f by objdump, use `.symver` to specify the certain version.
Tree-SHA512: e8d875652003618c73e019ccc420e7a25d46f4eaff1c7a1a6bfc1770b3b46f074b368b2cb14df541b5ab124cca41dede4e28fe863a670589b834ef6b8713f9c4
98d842cb52 travis: Build with --enable-debug (x86_64-unknown-linux-gnu) (practicalswift)
94e52d13db Add -ftrapv to DEBUG_CXXFLAGS when --enable-debug is used (practicalswift)
Pull request description:
By generating a trap for signed overflow on addition, subtraction, multiplication operations in the Travis testing we are more likely to identify problematic code prior to merging it.
Tree-SHA512: 47712da53b4ff451b8f22f16ddc3b53100a09060a3b04cda4b8fbbb74e6f666fc07a9cc7abc64cacb87a0aa3f62dc8e3c91a1a0ed12bf82bb2a5624a5d104389
e90e3e684ffa7b25f0dfb5b45e70bb0c358261fb build: fix sysctl() detection on macOS (fanquake)
Pull request description:
[`sysctl()` on *BSD](https://www.unix.com/man-page/FreeBSD/3/sysctl/) takes a "const int *name", whereas [`sysctl()` on macOS](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html)
it takes an "int *name". So our configure check and `sysctl()` detection on
macOS currently fails:
```bash
/usr/include/sys/sysctl.h:759:9: note: candidate function not viable:
no known conversion from 'const int [2]' to 'int *' for 1st argument
int sysctl(int *, u_int, void *, size_t *, void *, size_t);
```
The simplest change seems to be to change the param to a "int *name", which
will work during configure on macOS and *BSD systems.
For consistency I've changed both calls, but note that macOS doesn't
have `KERN_ARND`, so that check will always fail regardless. We can revert/add
documentation if preferred.
ACKs for top commit:
laanwj:
Re-ACK e90e3e684ffa7b25f0dfb5b45e70bb0c358261fb
Tree-SHA512: 29e9348136fc72882f63079bf10d2490e845d7656aae2c003e282bea49dd2778204a7776a67086bd88c2852af9a07dd04ba358eede7e37029e1c10f73c85d6a5
* compat: remove bswap_* check on macOS
This was originally added in #9366 to fix the gui build, as
Protobuf would also define these macros. Now that we're no-longer
using Protobuf, remove the additional check.
* build: skip building OpenSSL lib_ssl
* build: remove OpenSSL from Qt build
More info available from:
https://doc.qt.io/qt-5/ssl.html#enabling-and-disabling-ssl-support
* build: remove EVP_MD_CTX_new detection
This was added in #9475 to fix LibreSSL compatibility for
BIP70, so is no longer required.
* build: remove SSL lib detection
* gui: update BIP70 support message
* build: remove BIP70 entries from macOS Info.plist
* gui: remove payment request file handling from OpenURI dialog
* gui: remove BIP70 Support
* build: remove protobuf from depends and contrib
80e78b6a0479094cae642726f74a17d09b708ddc build: pass win32-dll to LT_INIT() (fanquake)
Pull request description:
This is the recommended way to support building PE DLLs with modern mingw
toolchains and libtool. I made a similar change upstream in the secp256k1
repo: https://github.com/bitcoin-core/secp256k1/pull/1022. Note that we already
pass `-no-undefined` to our libtool LDFLAGS.
> This option should be used if the package has been ported to build clean
> dlls on win32 platforms.
> If this macro is not used, libtool will assume that the package libraries
> are not dll clean and will build only static libraries on win32 hosts.
See:
https://www.gnu.org/software/libtool/manual/libtool.html#LT_005fINIThttps://www.gnu.org/software/gnulib/manual/html_node/Libtool-and-Windows.htmlhttps://autotools.io/libtool/windows.htmlhttps://github.com/bitcoin-core/secp256k1/issues/923
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
a504bac1c81818e2fa7e14d4b1e2ddf665b9b79683fff4390ec1d76335157012 guix-build-80e78b6a0479/output/aarch64-linux-gnu/SHA256SUMS.part
ef9193402c261adb993f6644de3f49858acb6d120002505e0def4827b8772294 guix-build-80e78b6a0479/output/aarch64-linux-gnu/bitcoin-80e78b6a0479-aarch64-linux-gnu-debug.tar.gz
030961da6966a14d3dd7322dc7559dfdc0bdeb9f39d042f379c41bab98303d28 guix-build-80e78b6a0479/output/aarch64-linux-gnu/bitcoin-80e78b6a0479-aarch64-linux-gnu.tar.gz
c485e456d325cdd64111eefe36b007e7bcb9e5eb61b1ab752e601023f5853e55 guix-build-80e78b6a0479/output/arm-linux-gnueabihf/SHA256SUMS.part
ff0481c57a3ab15c9651ead7b77990c37af9360bfbc1f5285ad5f7d0c66f5acc guix-build-80e78b6a0479/output/arm-linux-gnueabihf/bitcoin-80e78b6a0479-arm-linux-gnueabihf-debug.tar.gz
5f582e30bbdba9df175bf4c5d4aae64e2a1cf572086390ae6962d3ee9f0325a9 guix-build-80e78b6a0479/output/arm-linux-gnueabihf/bitcoin-80e78b6a0479-arm-linux-gnueabihf.tar.gz
e96c601af96e851a0351c6f8975feb47623a2dd5e3dd2c15bcdfe8435f845538 guix-build-80e78b6a0479/output/arm64-apple-darwin/SHA256SUMS.part
a50db7a8a9b6415842807644760110f2e01665b922b2762634d94e2b497cbd4a guix-build-80e78b6a0479/output/arm64-apple-darwin/bitcoin-80e78b6a0479-arm64-apple-darwin.tar.gz
0f3707a2423483f84be5edff91f8e657cf71ab097d2550f4369760ac8c6a1644 guix-build-80e78b6a0479/output/arm64-apple-darwin/bitcoin-80e78b6a0479-osx-unsigned.dmg
33252a9895c013cfbea06444d6372a23cc555831e4675705b4d7d6b065f06cff guix-build-80e78b6a0479/output/arm64-apple-darwin/bitcoin-80e78b6a0479-osx-unsigned.tar.gz
2ab70177c80c36e98018d07e2aece084c7d3d604e7dc12d2df2e1a077e06b983 guix-build-80e78b6a0479/output/dist-archive/bitcoin-80e78b6a0479.tar.gz
cc0237b05948472efa61f7d5a666d8e97b5abeb7f498f3f72d46ff69be38bcf4 guix-build-80e78b6a0479/output/powerpc64-linux-gnu/SHA256SUMS.part
b3778fd81bf4e432ad1590792673c91d09c8f8f43daef4cbe0852bca49e1ed57 guix-build-80e78b6a0479/output/powerpc64-linux-gnu/bitcoin-80e78b6a0479-powerpc64-linux-gnu-debug.tar.gz
bebe78f0e6a062d943c99470f12bfc520381acec40e0409915cc8d5dccbe5999 guix-build-80e78b6a0479/output/powerpc64-linux-gnu/bitcoin-80e78b6a0479-powerpc64-linux-gnu.tar.gz
350f7b22562d8b6642f37afb3e192d36dbcb360a361c8b834d0f7d50401667b8 guix-build-80e78b6a0479/output/powerpc64le-linux-gnu/SHA256SUMS.part
9a488fbd71c53092feda8dfccecc4ae7d10aa2efe48f99f150cb2322bb28c5e6 guix-build-80e78b6a0479/output/powerpc64le-linux-gnu/bitcoin-80e78b6a0479-powerpc64le-linux-gnu-debug.tar.gz
06d3c472171124d6ca92f95f7d5cb7fc4a523c25396dbbb9522cab920867d3db guix-build-80e78b6a0479/output/powerpc64le-linux-gnu/bitcoin-80e78b6a0479-powerpc64le-linux-gnu.tar.gz
67d591d5f15933d56046d0b8208970dc812ddd240c14a4c3b635cdc256ae5205 guix-build-80e78b6a0479/output/riscv64-linux-gnu/SHA256SUMS.part
f9a853d703ac153748f3d9f60d4a74a72c75966dc1d3711b688ebd003ff9389c guix-build-80e78b6a0479/output/riscv64-linux-gnu/bitcoin-80e78b6a0479-riscv64-linux-gnu-debug.tar.gz
07554223c5ab3b940f53f9483054023e639d4e9902810b3d5c1875fd390064ea guix-build-80e78b6a0479/output/riscv64-linux-gnu/bitcoin-80e78b6a0479-riscv64-linux-gnu.tar.gz
294dc1274391b17fb750eac7c76e59c18e972ed3fbf8bccd53ba514843fbc59f guix-build-80e78b6a0479/output/x86_64-apple-darwin/SHA256SUMS.part
cc5c1256ca57f80d5ecb93fe2ac477f90945206430545b0463813f7099804f47 guix-build-80e78b6a0479/output/x86_64-apple-darwin/bitcoin-80e78b6a0479-osx-unsigned.dmg
c5ff5cf7a8119981f8a1aa2306ff9e84c60e5c9845836eb2562941801495c7de guix-build-80e78b6a0479/output/x86_64-apple-darwin/bitcoin-80e78b6a0479-osx-unsigned.tar.gz
5951712d82391ba0471f253a7f87701b464dad1a90bb1d91866b0c7c51164a8f guix-build-80e78b6a0479/output/x86_64-apple-darwin/bitcoin-80e78b6a0479-osx64.tar.gz
28f84ed57769a642b1679acf90fdaad7ac489d59598d4a8a859021d39a32d878 guix-build-80e78b6a0479/output/x86_64-linux-gnu/SHA256SUMS.part
f7c37c47ffaec6fbca36c3c4897b2df2fa7dd5327cb860501eec9d9e987ea5c7 guix-build-80e78b6a0479/output/x86_64-linux-gnu/bitcoin-80e78b6a0479-x86_64-linux-gnu-debug.tar.gz
c7c6db897a604e5a85f37938b763538751a133bbab90e80904d4b7198b227d95 guix-build-80e78b6a0479/output/x86_64-linux-gnu/bitcoin-80e78b6a0479-x86_64-linux-gnu.tar.gz
80b1e0e249cefe8941ca0e1a563f479c5e4408da6f0aa02c127182a09310dd8c guix-build-80e78b6a0479/output/x86_64-w64-mingw32/SHA256SUMS.part
e7f8b2cd0f0f465e80d96338dcc398306b321a9c99556ca1d39f094752702a21 guix-build-80e78b6a0479/output/x86_64-w64-mingw32/bitcoin-80e78b6a0479-win-unsigned.tar.gz
5191f309c758135fd597df6bc9ef9e2c2746947abb74b38c32e5b6e073fa0995 guix-build-80e78b6a0479/output/x86_64-w64-mingw32/bitcoin-80e78b6a0479-win64-debug.zip
1569de943ca054841141c700f1d4fca2658228b85eee1f44d201b0c881218ef0 guix-build-80e78b6a0479/output/x86_64-w64-mingw32/bitcoin-80e78b6a0479-win64-setup-unsigned.exe
c8d78aeedeeaf7af4d325d38fb5e2307965b0080ce08a8cde802afaaa73f157d guix-build-80e78b6a0479/output/x86_64-w64-mingw32/bitcoin-80e78b6a0479-win64.zip
```
ACKs for top commit:
hebasto:
ACK 80e78b6a0479094cae642726f74a17d09b708ddc
Tree-SHA512: fb4a6a443288723776491a9795429273b4a454cfd8230e75570d44fcd71037dc784a2061f6a979322ebc8f9b4131dfbb0494146ab3863f94829e72922be4ec07
fac4be30482c21ac330e09ef8756c49e37faa6fa fuzz: Configure check for main function (take 2) (MarcoFalke)
Pull request description:
Actually fix https://github.com/google/honggfuzz/issues/336#issuecomment-702972138
Follow-up to #20065
Steps to test: `honggfuzz` section in doc/fuzzing.md
ACKs for top commit:
practicalswift:
cr ACK fac4be30482c21ac330e09ef8756c49e37faa6fa: patch looks correct!
Tree-SHA512: 893768c80439fe5d90b883ade89dc02f5bb80e27637916cf5575b6a9ed0b1c04942ff851342f5bbabb8666e6696715427feeb98f5301ad23c7b87b09e5872f97
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
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
fae7a1c18803675e70b9bf66575e1e0a6e01f6f6 fuzz: Configure check for main function (MarcoFalke)
Pull request description:
Instead of the PP jungle, use a proper configure check
Fixes https://github.com/google/honggfuzz/issues/336#issuecomment-702972138
ACKs for top commit:
practicalswift:
ACK fae7a1c18803675e70b9bf66575e1e0a6e01f6f6
Tree-SHA512: 2e55457d01f9ac598bb1e119d8b49dca55a28f88ec164cee6b5f071c29e9791f5a46cc8ee2b801b3a3faf906348da964ce32e7254da981c1104b9210a3508100
aaa1d03d3acebeb44fdd40a302f086aad3d329ce Add optimized sha256d64_arm_shani::Transform_2way (Pieter Wuille)
fe0629852aaf3a26f291bfa535e7e455fe7bea06 Implement sha256_arm_shani::Transform (Pavol Rusnak)
48a72fa81f80c8a3c7c6de8339b5feb361dece1c Add sha256_arm_shani to build system (Pavol Rusnak)
c2b79342506e24e9b7100fb7a6025dc870375ef6 Rename SHANI to X86_SHANI to allow future implementation of ARM_SHANI (Pavol Rusnak)
Pull request description:
This PR adds support for ARMv8 SHA2 Intrinsics.
Fixes https://github.com/bitcoin/bitcoin/issues/13401 and https://github.com/bitcoin/bitcoin/issues/17414
* Integration part was done by me.
* The original SHA2 NI code comes from https://github.com/noloader/SHA-Intrinsics/blob/master/sha256-arm.c
* Minor optimizations from https://github.com/rollmeister/bitcoin-armv8/blob/master/src/crypto/sha256.cpp are applied too.
* The 2-way transform added by @sipa
ACKs for top commit:
laanwj:
Code review and lightly tested ACK aaa1d03d3acebeb44fdd40a302f086aad3d329ce
Tree-SHA512: 9689d6390c004269cb1ee79ed05430d7d35a6efef2554a2b6732f7258a11e7e959b3306c04b4e8637a9623fb4c12d1c1b3592da0ff0dc6d737932db302509669
# Conflicts:
# configure.ac
# src/Makefile.am
# src/crypto/sha256.cpp
f2747d1602ec4e1128356b861b2167daf66a845b build: Restrict check for CRC32C intrinsic to aarch64 (W. J. van der Laan)
Pull request description:
`crc32c`'s hardware accelerated code doesn't handle ARM 32-bit at all, but only 64-bit. Make the check in `configure.ac` check for this architecture explicitly. This change does not affect non-ARM architectures.
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 can cause this check to succeed on armhf (as reported on IRC). So make the 64-bit platform requirement explicit.
(details: while the check already explicitly checks the `__crc32d` intrinsic, which strictly doesn't exist on 32-bit ARM, this is not enough! gcc happens to helpfully emulate it:
> These built-in intrinsics for the ARMv8-A CRC32 extension are available when the -march=armv8-a+crc switch is used "uint32_t __crc32d (uint32_t, uint64_t)" Form of expected instruction(s): Two crc32w r0, r0, r0 instructions for AArch32
)
ACKs for top commit:
luke-jr:
re-tACK f2747d1602ec4e1128356b861b2167daf66a845b
jarolrod:
ACK f2747d1602ec4e1128356b861b2167daf66a845b
Tree-SHA512: e5f05f05eeec310ac42685621d86862735586be66dc378db404ec9414ac5aaea7c53d76d76d875b15b11924eee6714076120c07b077183fd7af898704fd81823
819d03b932134ee91df3b0fe98a481a331ce57bf refactor: took out unused member functions (Zero)
ed69213c2b2a99023bdee5168614cb8b71990f5f build: enable unused member function diagnostic (Zero)
Pull request description:
This PR enables the `-Wunused-member-function` compiler diagnostic, as discussed in #19702.
> **Notice**: The `unused-member-function` diagnostic is only available on clang. Therefore, clang should be used to test this PR.
- [x] Include the `-Wunused-member-function`diagnostic in `./configure.ac`. (ed69213c2b2a99023bdee5168614cb8b71990f5f)
- [x] Resolve the reported warnings. (819d03b932134ee91df3b0fe98a481a331ce57bf)
Currently, enabling this flag no longer reports the following warnings:
> **Note**: output from `make 2>&1 | grep "warning: unused member function" | sort | uniq -c`
```
1 index/blockfilterindex.cpp:54:5: warning: unused member function 'DBHeightKey' [-Wunused-member-function]
2 script/bitcoinconsensus.cpp:50:9: warning: unused member function 'GetType' [-Wunused-member-function]
1 test/util_tests.cpp:1975:14: warning: unused member function 'operator=' [-Wunused-member-function]
```
All tests have passed locally (from `make check` & `src/test/test_bitcoin`).
This PR closes#19702.
ACKs for top commit:
practicalswift:
ACK 819d03b932134ee91df3b0fe98a481a331ce57bf - patch still looks correct :)
MarcoFalke:
ACK 819d03b932134ee91df3b0fe98a481a331ce57bf
pox:
Tested ACK 819d03b932134ee91df3b0fe98a481a331ce57bf with clang after `make clean`. No unused member function warnings.
theStack:
tested ACK 819d03b932134ee91df3b0fe98a481a331ce57bf
Tree-SHA512: 5fdfbbb02b3dc618a90a874a5caa5e01e596fc1d14a209e75a6981f01b253f9bca0cfac8fdd758dd7151986609fb76571c3745124a29cfd4f8cbb8d82a07272e
89fea68ffdbd97394d891177e664f896b3e7d1e6 build: don't pass -w when building for Windows (fanquake)
Pull request description:
This has been around since the introduction of autotools. However at
this point I'm not sure we'd ever want to suppress all warnings when
performing a build, and given that CXX FLAGS will have been overriden
when cross-compiling for Windows (using depends), this would rarely,
if-ever be used anyways.
From https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html:
> -w
>
> Inhibit all warning messages.
ACKs for top commit:
hebasto:
ACK 89fea68ffdbd97394d891177e664f896b3e7d1e6
Tree-SHA512: 2b5bdef7fff5c87b28199f5822cab3cdf600c90c01a40db5cd85053eef5dcb5816e2e97ff61a30ff94b4f0c6cb7be22beaef34d82235bdf05ff9da865d40b381
0164b0f5cf80cd00a4914d9fea0bcb9508cb7607 build: Remove WINVER pre define in Makefile.leveldb.inlcude (Chun Kuan Lee)
d0522ec94ebbaa564f5f6b31236d4df032664411 Drop defunct Windows compat fixes (Ben Woosley)
d8a299206780b38959d732cbe40ba1dd25834f0e windows: Call SetProcessDEPPolicy directly (Chun Kuan Lee)
1bd9ffdd44000b208d29d35451f4dc9f1ac9318f windows: Set _WIN32_WINNT to 0x0601 (Windows 7) (Chun Kuan Lee)
Pull request description:
The current minimum support Windows version is Vista. So set it to 0x0600
5a88def8ad/mingw-w64-headers/include/sdkddkver.h (L19)
Tree-SHA512: 38e2afc79426ae547131c8ad3db2e0a7f54a95512f341cfa0c06e4b2fe79521ae67d2795ef96b0192e683e4f1ba6183c010d7b4b8d6b3e68b9bf48c374c59e7d
abc147de95fb294a2c0a3105695e708517010322 build: remove WINDOWS_BITS from build system (fanquake)
Pull request description:
We no longer build/ship 32 bit windows executables.
ACKs for top commit:
laanwj:
LGTM ACK abc147de95fb294a2c0a3105695e708517010322
Tree-SHA512: 7101393cddb7e578740e4c79532dac981eb963630ce63c28dfebf0f5ecde266c1836ac0efd1fd82e6010a6151755ad2cc2b09bc2f67edd7c0c77060ac046a9cd
84edfc72e5eba3dde824ebd0626e97929a0b1bca Update doc and CI config (qmma)
48bcb2ac249e0e666ce638bb29124558b3283c16 Disable other targets when enable-fuzz is set (qmma)
Pull request description:
This is to fix https://github.com/bitcoin/bitcoin/issues/16094
When the `enable-fuzz` flag is set, disable all other binary targets.
ACKs for top commit:
MarcoFalke:
ACK 84edfc72e5eba3dde824ebd0626e97929a0b1bca (only checked that travis compiled this)
Tree-SHA512: f4ac80526388a67709986b22de88b00bf93ab44ae31a20bd4d8923a4982ab97e015a9f13010081d6ecf6c23ae8afeac7ca9d849d198ce6ebe239aa3127151efc
3c3e31c3a4 [tests] Add wallet-tool test (João Barbosa)
49d2374acf [tools] Add wallet inspection and modification tool (Jonas Schnelli)
Pull request description:
Adds an offline tool `bitcoin-wallet-tool` for wallet creation and maintenance.
Currently this tool can create a new wallet file, display information on an existing wallet, and run the salvage and zapwallettxes maintenance tasks on an existing wallet. It can later be extended to support other common wallet maintenance tasks.
Doing wallet maintenance tasks in an offline tool makes much more sense (and is potentially safer) than having to spin up a full node.
Tree-SHA512: 75a28b8a58858d9d76c7532db40eacdefc5714ea5aab536fb1dc9756e2f7d750d69d68d59c50a68e633ce38fb5b8c3e3d4880db30fe01561e07ce58d42bceb2b
8ac34140d5 configure: bitcoin-tx doesn't need libevent, so don't pull it in (Luke Dashjr)
Pull request description:
Tree-SHA512: e62f6c8d443923ec91cd15e11aeb5a6faeeade6824995fc01a87aaa47390c8bfded5ae573ce78e6b39f67179ab1851fb42270df739a07a19869b49bc2f747d04
* Merge #18750: build: optionally skip external warnings
ba8950ee0134a7958e3e9b041cd54d222feb09a1 build: optionally skip external warnings (Vasil Dimov)
Pull request description:
Add an option to `./configure` to suppress compilation warnings from
external headers. The option is off by default (no change in behavior,
show warnings from external headers).
This option is useful if e.g. Boost or Qt is installed outside of
`/usr/include` (warnings from headers in `/usr/include` are already
suppressed by default) and those warnings stand in the way of compiling
Bitcoin Core with `-Werror[=...]` or they just clutter the build output
too much and make our own warnings hard to spot.
`-isystem /usr/include` bricks GCC's `#include_next`, so we use
`-idirafter` instead. This way we don't have to treat `/usr/include`
specially.
ACKs for top commit:
practicalswift:
ACK ba8950ee0134a7958e3e9b041cd54d222feb09a1: diff looks correct!
hebasto:
ACK ba8950ee0134a7958e3e9b041cd54d222feb09a1, tested on Linux Mint 20 (x86_64).
luke-jr:
utACK ba8950ee0134a7958e3e9b041cd54d222feb09a1
Tree-SHA512: 9b54fae8590be6c79f2688a5aca09e0a9067f481dabecdd49bb278c08a62ac2b0cc704c894fbd53240e77ac84da0c7a237845df0a696cfbdb0359e1c8e2e10c9
* add --enable-suppress-external-warnings to matrix.sh
Co-authored-by: Wladimir J. van der Laan <laanwj@protonmail.com>
a2a04a5abb Bugfix: Only run bitcoin-tx tests when bitcoin-tx is enabled (Luke Dashjr)
92af71cea9 configure: Make it possible to build only one of bitcoin-cli or bitcoin-tx (Luke Dashjr)
Pull request description:
Includes #5618 (which the reasons for rejecting no longer hold true)
Tree-SHA512: f30a8e4a2f70166b7cabef77c4674163b3a9da14c6a547d34f00d1056a19bf4d23e22851eea726fad2afc8735d5473ae91122c770b65ac3886663dc20e2c5b70
399d84da3708719b063953107bab0f5f6493addb build: Only allow ASCII identifiers (Wladimir J. van der Laan)
Pull request description:
While emoji and other symbols in C++ identifers (as accepted by newer compilers) are fun, they might create confusion during code review, for example because some symbols look very similar. Forbid such extended identifiers for now.
This is done by providing `-fno-extended-identifiers`. Thanks to sipa for suggesting this compiler flag.
ACKs for top commit:
practicalswift:
ACK 399d84da3708719b063953107bab0f5f6493addb -- patch looks correct
promag:
ACK 399d84da3708719b063953107bab0f5f6493addb.
jonatack:
ACK 399d84da3708719b063953107bab0f5f6493ad
fanquake:
ACK 399d84da3708719b063953107bab0f5f6493addb - seems like a good sanity check to enable.
Tree-SHA512: 62bfbe8c7e0284ed505c2c8789c1ae74997202d90595f298c2ee1917e5d69fa9b7196a9404ba2cff61f3162b2bbb5616a1591bed3f0534c58617e22009291933
e8a8cff07c409c7eecd478d3df36c7ba92c59730 build: enforce minimum required Windows version (7) (fanquake)
Pull request description:
Instruct the linker to set the major & minor subsystem versions in the PE
header to 6 & 1 (NT 6.1 which corresponds to Windows 7). Similar to
the behaviour on macOS, the binary will now refuse to run on
unsupported versions of Windows, which, for us, is XP & Vista.
ACKs for top commit:
laanwj:
ACK e8a8cff07c409c7eecd478d3df36c7ba92c59730
Tree-SHA512: 2f7c6443b79b1c6b995e337452aa177e95b0a9c48e47bcf1893aad6fd598e45940ab8eaa5ee1c5d994a521239b4e1b55a55bb3e8ffe367e1349db2a46892a6d4
1a011b3a8285a21ca9618a35bb841d3f2d48b247 build: remove -Wdeprecated-register from NOWARN flags (fanquake)
Pull request description:
The `register` keyword was deprecated in C++11, and [removed in C++17](https://en.cppreference.com/w/cpp/keyword/register). Now that we require C++17, we shouldn't have to suppress warnings for a non-existent feature.
ACKs for top commit:
sipa:
utACK 1a011b3a8285a21ca9618a35bb841d3f2d48b247
hebasto:
ACK 1a011b3a8285a21ca9618a35bb841d3f2d48b247
Tree-SHA512: 7546b3870fe819507deea57d5c3179bc5debd4513df41b3f74d191995116b1507ff2a77cf2081ac32871194d4e5c2a2913c668c56244dff39853a5da18194f9f
cd24f37ea9168bd56b8c518ea6125e242cc4213d doc: Better explain GNU ld's dislike of ld64's options (fanquake)
Pull request description:
There's also now more than a single option being special cased for
darwin. If we didn't special case these options they would still end
up on the link line and the binaries produced would just segfault.
I'm going to plug #17874 here as well, because adding
`-fatal-warnings` to our `AX_CHECK_LINK_FLAG` calls would
mostly prevent this sort of option mangling from happening.
An example of the warning behaviour:
```bash
echo "int main() {}" | g++ -x c++ -std=c++11 -Wl,-dead_strip -
/usr/bin/ld: warning: cannot find entry symbol ad_strip; defaulting to 0000000000001040
nm -C a.out
0000000000001000 t _init
0000000000001040 T _start
U ad_strip
```
ACKs for top commit:
dongcarl:
ACK cd24f37ea9168bd56b8c518ea6125e242cc4213d
Tree-SHA512: 8c5ff11b647e7d44dbb3f509a07caf8606a6b481c114403f0de72b3ad65395dbe9a3436e731ae1b46a823431ed23c3c6aacab8942d78629d59cd8c258c5dbf02
acd644b83d789a6cdfbeda19732119534d10058e build: remove --large-address-aware linker flag (fanquake)
Pull request description:
This flag was used when building 32-bit Windows executables, which we no-longer
do, and is not accepted by the linker for any of the hosts we currently build
for. i.e:
```bash
checking whether the linker accepts -Wl,--large-address-aware... no
```
--large-address-aware
If given, the appropriate bit in the "Characteristics" field of the COFF
header is set to indicate that this executable supports virtual addresses
greater than 2 gigabytes. This should be used in conjunction with the /3GB
or /USERVA=value megabytes switch in the "[operating systems]" section of
the BOOT .INI. Otherwise, this bit has no effect. [This option is specific
to PE targeted ports of the linker]
You can check that the appropriate bit in the COFF header of our 64-bit
Windows binaries is still be set using dumpbin. i.e:
```powershell
dumpbin /headers .\bitcoind.exe
FILE HEADER VALUES
<snip>
26 characteristics
Executable
Line numbers stripped
Application can handle large (>2GB) addresses
```
ACKs for top commit:
laanwj:
ACK acd644b83d789a6cdfbeda19732119534d10058e
Tree-SHA512: 9711e07bc08e843fcefd0517091a59cb7670dd107d03623a146d03fe73054d0e64f78489490b37f4708eab2c4800037f923b9ec92e7f53c3df9a590242f52b55
836a3dc02c72f917db5be386b9b4787a59d48610 Avoid weak-linked getauxval support on non-linux platforms (like macOS) (Jonas Schnelli)
41a413b31746cc749f3c64ed8070cea9cc6cfdbe Define correct symbols for getauxval (Jonas Schnelli)
Pull request description:
PR #20358 made use of the two preprocessor symbols `HAVE_STRONG_GETAUXVAL` as well as `HAVE_WEAK_GETAUXVAL`.
These symbols have not been defined in configure.ac. They where only passed selective as CRC32 CPPFLAGS in https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.crc32c.include#L16.
PR #20358 would have broken the macOS build since `getauxval` is not supported on macOS (but weak-linking does pass).
This PR defines the two symbols correctly and reduces calls to `getauxval` to linux.
ACKs for top commit:
laanwj:
Code review ACK 836a3dc02c72f917db5be386b9b4787a59d48610
jonatack:
utACK 836a3dc02c72f917db5be386b9b4787a59d48610
Tree-SHA512: 6527f4a617b937f4c368a3cb1c162f1ac38a6f5e6341295554961eaf322906e9b27398a6f7b00819854ceebb5c828d3e6ce0a779edd769adc4053ce8beda3739
c78b123982d59fe2d633659f23d6893de627f3f6 build: add -bind_at_load to hardened LDFLAGS (fanquake)
Pull request description:
This performs the same function as `-Wl,-z,now`, except for ld on macOS.
You can check the binaries using `otool -l`, and looking for the `LC_DYLD_INFO_ONLY` section; `lazy_bind_off` and `lazy_bind_size` should both be 0.
This seems to be the case with our current release binaries. However we can make the check, and applying the flag explicit in configure.
man ld:
```bash
-bind_at_load
Sets a bit in the mach header of the resulting binary which tells dyld
to bind all symbols when the binary is loaded, rather than lazily.
```
TODO:
- [ ] Follow up with `MH_BINDATLOAD` flag.
ACKs for top commit:
theuni:
ACK c78b123982d59fe2d633659f23d6893de627f3f6.
Tree-SHA512: 12259558b84f7e3d75d6fcde63b517685e42b18fcf8e8cfcf347483c5ba089d3b4b6d330e7b7f61f83a328fe4d141b771e8e52ddee9cac6da87dfc073ab1183d
f7453dcc0386a4a1162ced1a490c096afa13178a build: remove linking librt for backwards compatibility (fanquake)
Pull request description:
Now that we require glibc 2.17+, see #17538, we can remove linking librt
for backwards compatibility purposes. The `clock_*` functions from librt
were merged into glibc as part of the [2.17 release](https://sourceware.org/ml/libc-announce/2012/msg00001.html):
* The `clock_*` suite of functions (declared in <time.h>) is now available
directly in the main C library. Previously it was necessary to link with
-lrt to use these functions. This change has the effect that a
single-threaded program that uses a function such as `clock_gettime' (and
is not linked with -lrt) will no longer implicitly load the pthreads
library at runtime and so will not suffer the overheads associated with
multi-thread support in other code such as the C++ runtime library.
Note that `librt` is already unused by the RISC-V and AARCH64 binaries as their librts don't export any `clock_*` functions. As an example, you can find a diff of the arm32 vs arm64 librt symbols [here](https://gist.github.com/fanquake/b08cb1f0d14df3133395d7796ebf030c).
Below is the library usage for the `v0.19.0.1` release (can delete these tables pre-merge).
#### RISC-V
```bash
riscv/bin/bitcoin-cli: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-riscv64-lp64d.so.1']
riscv/bin/bitcoin-qt: ['libpthread.so.0', 'libfontconfig.so.1', 'libfreetype.so.6', 'libxcb.so.1', 'libdl.so.2', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-riscv64-lp64d.so.1', 'libatomic.so.1']
riscv/bin/bitcoin-wallet: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-riscv64-lp64d.so.1', 'libatomic.so.1']
riscv/bin/bitcoind: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-riscv64-lp64d.so.1', 'libatomic.so.1']
riscv/bin/bitcoin-tx: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-riscv64-lp64d.so.1']
riscv/bin/test_bitcoin: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-riscv64-lp64d.so.1', 'libatomic.so.1']
```
#### AARCH64
```bash
aarch64/bin/bitcoin-cli: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-aarch64.so.1']
aarch64/bin/bitcoin-qt: ['libpthread.so.0', 'libfontconfig.so.1', 'libfreetype.so.6', 'libxcb.so.1', 'libdl.so.2', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-aarch64.so.1']
aarch64/bin/bitcoin-wallet: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-aarch64.so.1']
aarch64/bin/bitcoind: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-aarch64.so.1']
aarch64/bin/bitcoin-tx: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-aarch64.so.1']
aarch64/bin/test_bitcoin: ['libpthread.so.0', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-aarch64.so.1']
```
#### ARM LINUX GNUEABIHF
```bash
arm32/bin/bitcoin-cli: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-armhf.so.3']
arm32/bin/bitcoin-qt: ['libpthread.so.0', 'librt.so.1', 'libfontconfig.so.1', 'libfreetype.so.6', 'libxcb.so.1', 'libdl.so.2', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-armhf.so.3']
arm32/bin/bitcoin-wallet: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-armhf.so.3']
arm32/bin/bitcoind: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-armhf.so.3']
arm32/bin/bitcoin-tx: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-armhf.so.3']
arm32/bin/test_bitcoin: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-armhf.so.3']
```
#### LINUX X86_64
```bash
x86_64/bin/bitcoin-cli: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-x86-64.so.2']
x86_64/bin/bitcoin-qt: ['libpthread.so.0', 'librt.so.1', 'libfontconfig.so.1', 'libfreetype.so.6', 'libxcb.so.1', 'libdl.so.2', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-x86-64.so.2']
x86_64/bin/bitcoin-wallet: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-x86-64.so.2']
x86_64/bin/bitcoind: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-x86-64.so.2']
x86_64/bin/bitcoin-tx: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-x86-64.so.2']
x86_64/bin/test_bitcoin: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux-x86-64.so.2']
```
#### LINUX i686
```bash
i686/bin/bitcoin-cli: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux.so.2']
i686/bin/bitcoin-qt: ['libpthread.so.0', 'librt.so.1', 'libfontconfig.so.1', 'libfreetype.so.6', 'libxcb.so.1', 'libdl.so.2', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux.so.2']
i686/bin/bitcoin-wallet: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux.so.2']
i686/bin/bitcoind: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux.so.2']
i686/bin/bitcoin-tx: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux.so.2']
i686/bin/test_bitcoin: ['libpthread.so.0', 'librt.so.1', 'libm.so.6', 'libgcc_s.so.1', 'libc.so.6', 'ld-linux.so.2']
```
ACKs for top commit:
laanwj:
ACK f7453dcc0386a4a1162ced1a490c096afa13178a
Tree-SHA512: b418260edcda88583abfa386a592ebfb977d111e8e2ba887a30bf830b0b10dba429b9cfd615fad453ff0bb824225914ccb91433064b158ae1fbb9d20fc0b9937
58c5cc9ce7 Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (James Hilliard)
Pull request description:
This change ensures that the GUI is still built even if protobuf is missing unless --enable-bip70 is passed to configure. If protobuf is present bip70 support will be compiled in unless --disable-bip70 is passed.
Tree-SHA512: 432d2fbefec5436503d8aa8994e4efaf760d88bfd5249af031b502b356852e8fd56362f86420f9ffe78498649079d0f1b68c327960b215d83c275800626ad275
48439b3c10391e5f5555c7d98e1a99706b77eaf7 Don't link SSL_LIBS with GUI unless BIP70 is enabled (James Hilliard)
fbb643d2a55ade3c06593a7490601acd2e36dce8 Add BIP70 deprecation warning (James Hilliard)
38b98507cdda02ff02a524d41bcc3427ca9e4fd9 qt: cleanup: Move BIP70 functions together in paymentserver (Wladimir J. van der Laan)
9dcf6c0dfec51f2a49edef537f377422d6dbdceb build: Add --disable-bip70 configure option (Wladimir J. van der Laan)
Pull request description:
This is based off of #11622 and adds a deprecation warning when a BIP70 URL is used.
Rational:
- BIP70 increases attack surface in multiple ways and is difficult for third party wallets to implement in a secure manner
- Very few merchants use the standard BIP70 variant supported by Bitcoin Core
- The one major payment processor that doesn't support BIP21 and currently uses a customized non-standard version of BIP70 has indicated that "Unfortunately the original BIP70 is not useful for us."
Tree-SHA512: 1e16ee8d2cdac9499f751ee7b50d058278150f9e38a87a47ddb5105dd0353cdedabe462903f54ead6209b249b249fe5e6a10d29631531be27400f2f69c25b9b9
480e3415d7 configure: Add flag for enabling thread_local. (Carl Dong)
Pull request description:
- When aiming for glibc compatibility, don't use thread_local. Fixes#15958.
- FreeBSD has a buggy thread_local, don't use it. Fixes#16055.
I've done a Gitian build on my local machine and the symbol tests seem to pass.
ACKs for commit 480e34:
MarcoFalke:
utACK 480e3415d738a4e0e2ad9774c43f29937178ecae
fanquake:
tACK 480e341
Tree-SHA512: 334f21f7cf271c261b115a6410afd4ed4db3e84ad79b98c6c684c1dfa42b081f16d58e77695929e27b0fa173a894b959a327fe82821a3f3ed708b305a906ddd3
75a4bf699fa6bdefa1b3d8cd405ea822d6ee01c0 Update release-process.md to include RC version bumping (Andrew Chow)
04b0bc7425e43de90856beeb1f33653db109fecd build: include rc number in version number (Andrew Chow)
895e6bbb2241e9175463734f3677398a9f38f0f8 build: if VERSION_BUILD is non-zero, include it in the package version (Andrew Chow)
Pull request description:
As noted on IRC, the filenames of the gitian build results do not contain the 4th digit of the version number if it has one, e.g. 0.17.0.1 produces files with the number 0.17.0. Furthermore, when RC's are built, the resulting filenames are of the release version and do not include `rc` in them. This occurs because `configure.ac` is written to create version numbers of the form `major.minor.rev` instead of `major.minor.rev.build` and without any rc version as it does not handle rc numbers.
This PR changes `configure.ac` to include the build number if it is greater than 0. It will also include the rc number if it is greater than 0. So the filenames of the gitian builds will now contain the full version number.
This behavior can be tested by setting `_CLIENT_VERSION_BUILD` and `_CLIENT_VERSION_RC` to non-zero values and then doing `make dist`. A tar file should be created with the correct versioning.
Tree-SHA512: b77990485f2c7770be897dc136737cd805306afff9882ebef7170741f363203587356ccf8bec83163268ace1bd77433fbd2ba8c213f993677bfb867d99a0bbe7
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
* build: detect the presence of libgmp before generating Makefile
* depends: add arximboldi/immer@v0.6.2 as a package and add detection
* depends: remove immer from source tree, build using package only
* Drop immer refs from tools
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
7abac98d3e3c1bc8ad66cb5c05184b9c5cc674d5 configure: Support -f{debug,macro}-prefix-map (Anthony Towns)
Pull request description:
When bitcoin is checked out in two directories (eg via git worktree) object files between the two will differ due to the full path being included in the debug section. `-fdebug-prefix-map` is used to replace this with "." to avoid this unnecessary difference and allow ccache to share objects between worktrees (provided the source and compile options are the same).
Also provide `-fmacro-prefix-map` if supported so that the working dir is not encoded in `__FILE__` macros.
ACKs for top commit:
practicalswift:
cr ACK 7abac98d3e3c1bc8ad66cb5c05184b9c5cc674d5: patch looks correct
fanquake:
ACK 7abac98d3e3c1bc8ad66cb5c05184b9c5cc674d5
Tree-SHA512: b6a37c1728ec3b2e552f244da0e66db113c1e7662c7ac502e12ff466f3dbfbfefae12695ca135137c50dbb1c4c5d84059116c0cd09b391a17466dc77b8726679
ef3d4ce4c301caa57946f772f554678cd872fca8 build: call AC_PATH_TOOL for dsymutil in macOS cross-compile (fanquake)
Pull request description:
While testing #19530 I noticed that we couldn't call [`dsymutil`](https://www.llvm.org/docs/CommandGuide/dsymutil.html) after LTO:
```bash
../libtool: line 10643: x86_64-apple-darwin16-dsymutil: command not found
```
This updates configure to call `AC_PATH_TOOL` so that we end up with the
full path to dsymutil, similar to `otool` and `install_name_tool`, ie:
`/bitcoin/depends/x86_64-apple-darwin16/share/../native/bin/x86_64-apple-darwin16-dsymutil`.
ACKs for top commit:
laanwj:
Code review ACK ef3d4ce4c301caa57946f772f554678cd872fca8
theuni:
ACK ef3d4ce4c301caa57946f772f554678cd872fca8.
Tree-SHA512: e4fa93e7f9f7945289143dfe2a6645ad8ee7f3bee0793412b3509901a30566d6f952e3b39e0e525a54f8dbd0c480f8da70fc6cb80b07800d11b0c6071fbb7466
fa84edb93c85f7709fc53abf9c6daae5d1bb3b28 build: don't warn when doxygen isn't found (fanquake)
Pull request description:
Doxygen isn't so important that we need to warn when it is missing. I'd
assume it might even be missing more often than not for most builds.
ACKs for top commit:
MarcoFalke:
Fine with me ACK fa84edb93c85f7709fc53abf9c6daae5d1bb3b28
hebasto:
ACK fa84edb93c85f7709fc53abf9c6daae5d1bb3b28, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: 793ebf01a8a5d48b78a70fdef0022633fca59b30074c960ebb21589e3bd98992b8304621a2d999195d12172ed30fe9eefeeb2a952d58853cf58e8d9902b0090c
* Update to leveldb upstream using subtree merge
* Import crc32c using subtree merge as as 'src/crc32c'
* build: Update build system for new leveldb
Upstream leveldb switched build systems, which means we need to define
a few different values.
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
* doc: Add crc32c subtree to developer notes
* test: Add crc32c to subtree check linter
* test: Add crc32c exception to various linters and generation scripts
* build: Add LCOV exception for crc32c
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
* build: CRC32C build system integration
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
0c63f808542ba02fc41aa90b1d96e9123f16d8ad build: Suppress -Wdeprecated-copy warnings (Hennadii Stepanov)
Pull request description:
Tomorrow, on Apr 23 the Ubuntu 20.04 release is expected. It packaged with Qt 5.12 LTS that has a nasty peculiarity to cause modern compilers, including Clang 10.0 and GCC 9.3, to emit spammy `-Wdeprecated-copy` warnings (#15822, #18419).
This PR suppress such warnings _temporarily_, until the [upstream is fixed](https://codereview.qt-project.org/c/qt/qtbase/+/272258).
Here are some affected systems (with system packages):
- Ubuntu 20.04 LTS + Qt 5.12.8 LTS + { Clang 10.0 | GCC 9.3 }
- Fedora 32 + Qt 5.13.2 + Clang 10.0
Reference: [QTBUG-75210](https://bugreports.qt.io/browse/QTBUG-75210)
Also see **fanquake**'s [comment](https://github.com/bitcoin/bitcoin/pull/18738#issuecomment-622956100).
ACKs for top commit:
MarcoFalke:
ACK 0c63f808542ba02fc41aa90b1d96e9123f16d8ad seems fine to disable this warning for the 0.21.0 release temporarily and then enable it for 0.22.0, when boost is removed.
fanquake:
ACK 0c63f808542ba02fc41aa90b1d96e9123f16d8ad - I think it's ok to suppress these for now, given that `-Wdeprecated-copy` is enabled (via `-Wextra`) in GCC 9 and Clang 10. The Qt output is pretty noisy, and there's a few warnings from Boost as well.
Tree-SHA512: 7064a3272bc9eae00b73a16c421ac58be148f374cbef87320e8f092f52761f6e98166eff60346b70867f8a69a9698a79455dc16b42d92f8fbe7c56519571ac08
a029805f57fa9a4ab9867c0d1e865675d57537c7 build: remove -Qunused-arguments workaround for clang + ccache (fanquake)
Pull request description:
This was added in 386efb7695 to address spammy Clang warnings when building with ccache.
The issue was addressed in [ccache 3.2](https://bugzilla.samba.org/show_bug.cgi?id=8118), and from a look at most major distros, it's only Debian Jessie that has a version of ccache older than that ([3.1](https://packages.debian.org/jessie/ccache)).
Therefore I think it's acceptable to drop this workaround, and re-enable warnings for unused driver arguments (when compiling using Clang and ccache).
ACKs for top commit:
hebasto:
ACK a029805f57fa9a4ab9867c0d1e865675d57537c7.
vasild:
utACK a029805f57fa9a4ab9867c0d1e865675d57537c7
Tree-SHA512: f887b9bd12f9c1c8d209943b86e8dafe33cfd1572912f2cafabe08ffe403973e48f0f7289280a8c6db9263c57aad43fbd4bb72f42db762eb090f3b1ef0538f43
4f4ae6f97e210fa0a2aa274bcd2a77a226fe6a7e build: set AC_PREREQ to 2.69 (fanquake)
Pull request description:
We use build macros such as `AX_CHECK_LINK_FLAG`, that require >=2.64, so our configure should also require Autoconf >= 2.64. The build would already blow up if 2.64 wasn't available. i.e:
```bash
configure.ac:320: error: Autoconf version 2.64 or higher is required
build-aux/m4/ax_check_link_flag.m4:74: AX_CHECK_LINK_FLAG is expanded from...
```
For reference, Autoconf 2.69 was released in [April of 2012](https://lists.gnu.org/archive/html/autoconf/2012-04/msg00041.html).
See the [Autoconf Versioning docs](https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Versioning.html) for more info on `AC_PREREQ`.
ACKs for top commit:
hebasto:
re-ACK 4f4ae6f97e210fa0a2aa274bcd2a77a226fe6a7e, Autoconf 2.69 seems wide available.
laanwj:
ACK 4f4ae6f97e210fa0a2aa274bcd2a77a226fe6a7e
Tree-SHA512: b77de9164ae6667513d40edaf9e16c6e7734c100643297b2dbb2ff54072774fdeab7b3b15d52979b99e204c1c4dcca4725ff155d7f6fdab7a867629130e10185
ddc7e42d600a0cb3e763cda0dc04a1f2f34e9440 build: Set minimum Automake version to 1.13 (Hennadii Stepanov)
Pull request description:
This PR suggests to set the required minimum Automake version to `1.13` explicitly for the following reasons:
- it guarantees that [CVE-2012-3386](https://lists.gnu.org/archive/html/automake/2012-07/msg00023.html) has been fixed
- `AC_CONFIG_MACRO_DIR` macro support, which we already use; from the [release notes](https://lists.gnu.org/archive/html/automake/2012-12/msg00038.html):
> Improvements to aclocal and related rebuilds rules:
> - Autoconf-provided macros AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS are now traced by aclocal, and can be used to declare the local m4 include directories. Formerly, one had to specify it with an explicit '-I' option to the 'aclocal' invocation.
- `AM_SILENT_RULES` macro support (since version `1.11`)
Automake `1.13` requires Autoconf `2.65` or greater. We already have `2.69` since #17769.
---
For reference, Automake `1.13` was released in [December of 2012](https://lists.gnu.org/archive/html/automake/2012-12/msg00038.html).
CentOS 7 uses Automake [`1.13.4`](https://centos.pkgs.org/7/centos-x86_64/automake-1.13.4-3.el7.noarch.rpm.html)
See the Automake docs for more info:
- [`AM_INIT_AUTOMAKE`](https://www.gnu.org/software/automake/manual/automake.html#Public-Macros)
- [List of Automake options](https://www.gnu.org/software/automake/manual/automake.html#List-of-Automake-options)
ACKs for top commit:
laanwj:
so also ACK ddc7e42d600a0cb3e763cda0dc04a1f2f34e9440
fanquake:
ACK ddc7e42d600a0cb3e763cda0dc04a1f2f34e9440 - I think adding a minimum required version here is fine. I'd be surprised if someone who is currently building Bitcoin Core was unable to after this change.
Tree-SHA512: a1f97864bc3a513450c03d041498f28e823e6f8cd9710d81df081435d72bd4b6cd2f3deb997dbf902f950215a859e48a2ee7ca1f8ebf4271778dd951ab78abf4
bd44711e1bb2eee7646f2f8e2e8763d1c216bdb9 build: pass -dead_strip_dylibs to ld on macOS (fanquake)
Pull request description:
This strips some unused dylibs from bitcoin-qt.
```diff
otool -L src/qt/bitcoin-qt
/usr/lib/libSystem.B.dylib
- /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
-/System/Library/Frameworks/Security.framework/Versions/A/Security
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
-/System/Library/Frameworks/AGL.framework/Versions/A/AGL
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
/usr/lib/libc++.1.dylib
/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
/System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
/usr/lib/libobjc.A.dylib
```
`AGL` - ObjC wrapper for OpenGL.
`DiskArbitration` - mount/unmount notifications and events.
`Security` - low level security operations, authentication services.
From `man ld`:
```
Remove dylibs that are unreachable by the entry point or exported symbols.
That is, suppresses the generation of load command commands for dylibs
which supplied no symbols during the link. This option should not be
used when linking against a dylib which is required at runtime for
some indirect reason such as the dylib has an important initializer.
```
ACKs for top commit:
theuni:
ACK bd44711e1bb2eee7646f2f8e2e8763d1c216bdb9.
Tree-SHA512: 9592ce2966d28cb6c58e01efd401f56a4baa5dc5be5313f4fe8454632b578608be65a23c8602772049cd4655a9cb020fdd40d6622a244c301920d8c3db43f99a
651c636f9ed4a60c4cd003e566e3ac6ae6eda3ed build: Fix configure report about qr (Hennadii Stepanov)
Pull request description:
On master (b7bc9b8330096d1f4f1fa563b855b88da425226e):
```
$ apt list libqrencode-dev
Listing... Done
libqrencode-dev/bionic 3.4.4-1build1 amd64
$ ./configure | grep -i qr
checking for QR... no
checking whether to build GUI with support for QR codes... no
with qr = auto
```
With this PR:
```
$ apt list libqrencode-dev
Listing... Done
libqrencode-dev/bionic 3.4.4-1build1 amd64
$ ./configure | grep -i qr
checking for QR... no
checking whether to build GUI with support for QR codes... no
with qr = no
```
ACKs for top commit:
laanwj:
Concept and light code review ACK 651c636f9ed4a60c4cd003e566e3ac6ae6eda3ed
fanquake:
ACK 651c636f9ed4a60c4cd003e566e3ac6ae6eda3ed
Tree-SHA512: 8959b1c7da5b28d06affcdd27ff4e455f1f7d9c8363dbde8ef07aaf79139ec8bc7ce25610b28e1d90c7e168573ee90ac9ab359bf10c667d0254507f8a880a935
44f7a8d7a774f82417106c452d793e6f091bc23e Disable _FORTIFY_SOURCE when enable-debug (Andrew Chow)
Pull request description:
The `_FORTIFY_SOURCE` macro is enabled by default when hardening is enabled, but it requires optimization in order to be used. Since we disable all optimization with `--enable-debug`, this macro doesn't actually do anything and instead just causes a lot of warnings to be printed. This PR explicitly disables `_FORTIFY_SOURCE` so that these useless warnings aren't printed.
ACKs for top commit:
laanwj:
Thanks. ACK 44f7a8d7a774f82417106c452d793e6f091bc23e
Tree-SHA512: e9302aef794dfd9ca9d0d032179ecc51d3212a9a0204454419f410011343b27c32e6be05f385051b5b594c607b91b8e0e588f644584d6684429a649a413077d9
30fc1a3f5470cb347eb4aed281242f120510466f build: Remove workaround for ancient libtool (Hennadii Stepanov)
6ca01b9a104ebadbe7e180cb2b9d390f7c09b4ab build: Ensure a minimal version of libtool (Hennadii Stepanov)
Pull request description:
Since libtool 1.5.2, on Linux libtool no longer sets RPATH for any directories in the dynamic linker search path, so there is no longer an issue.
This commit reverts a98356fee8.
Refs:
- https://wiki.debian.org/RpathIssue
- [Debian jessie has libtool 2.4.2](https://packages.debian.org/jessie/libtool)
ACKs for top commit:
laanwj:
ACK 30fc1a3f5470cb347eb4aed281242f120510466f
Tree-SHA512: fab56265d4d2c96216a353cc076c6f510e15748d8134f97bae2f67b6d8c0b6a1a9f362d2ab23b19ccc3a8bba8eac3bb1668fc3e42037590f63a7ab4819c9ee15
d6ac25bdd96589a71006e3ab3f303b091ffaa9e4 autoconf: Sane --enable-debug defaults. (Carl Dong)
Pull request description:
```
Don't optimize even if variables adhere to as-if rule. This is a
somewhat sane default for debugging.
```
-----
Fixes: #14830
This is more of a "do something dumb and have people correct you" kind of PR. The end goal is to have a configure flag that will allow for debugging without annoying "optimized out" messages, for developer experiences' sake. This is the minimal diff, but people have suggested `--enable-debug-slow` in the past.
ACKs for top commit:
jonasschnelli:
Tested ACK d6ac25bdd96589a71006e3ab3f303b091ffaa9e4
Tree-SHA512: 7a5576ad1d33850aff1445ccb71b133f654b455da2d1daed2ed1b82ea773965790a62895aeeab74b23a25513ab96dddb670f9dbc593dd0b8c030694206a99ccf
bf72b8a5551868433ae6fa1824915255f104b208 build: disable libsecp256k1 benchmarks (fanquake)
Pull request description:
These were previously disabled, but upstream changed to having benchmarks enabled by default
in https://github.com/bitcoin-core/secp256k1/pull/480 and we pulled that change in as part of #15703.
ACKs for top commit:
laanwj:
ACK bf72b8a5551868433ae6fa1824915255f104b208
real-or-random:
ACK bf72b8a5551868433ae6fa1824915255f104b208 I only looked at the diff
practicalswift:
ACK bf72b8a5551868433ae6fa1824915255f104b208 -- diff looks correct
Tree-SHA512: f4c99c774c8bfd37f98fa200667530988ef8da61920fafdff7e929d9dc5dd8304981b625611f6c3fbc525172d269a2a1d33e592297bd8ff418dff11b05b5e204
