Commit Graph

606 Commits

Author SHA1 Message Date
Kittywhiskers Van Gogh
d37f30ce46 merge bitcoin#20476: Add test for ELF symbol-check 2023-01-18 19:02:39 -06:00
Kittywhiskers Van Gogh
29c885c9f7 merge bitcoin#20434: Parse ELF directly for symbol and security checks 2023-01-18 19:02:39 -06:00
Kittywhiskers Van Gogh
ef69317b59 merge bitcoin#19525: add -Wl,-z,separate-code to hardening flags 2023-01-18 19:02:39 -06:00
UdjinM6
e32e212168 chore: bump COPYRIGHT_YEAR to 2023 2023-01-13 00:49:04 +03:00
Kittywhiskers Van Gogh
dae66d4fc4 build: add mimalloc's Win32 API dependencies 2023-01-02 12:43:49 +05:30
Kittywhiskers Van Gogh
faeb154a01 build: restore support for building immer from local subtree 2022-12-01 00:51:07 +05:30
Kittywhiskers Van Gogh
305abe91f9
build/depends: commit dashpay/bls-signatures@66ee820f to source tree as vendored (#5077)
* Squashed 'src/dashbls/' content from commit 66ee820fbc

git-subtree-dir: src/dashbls
git-subtree-split: 66ee820fbc9e3b97370db8c164904af48327a124

* build: stop tracking build-system generated relic_conf.h.in

* build: add support for building bls-signatures from local subtree

* build: add exclusions to linting scripts and filters

* build: drop bls-signatures (bls-dash) from depends
2022-11-22 11:34:46 -06:00
PastaPastaPasta
6ee156c69e
chore: bump version to 19.0.0 (#5080)
* chore: bump version to 19.0.0

* drop rc

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2022-11-22 11:32:53 -06:00
PastaPastaPasta
46b312381d
chore: bump to 18.2.0-rc.1 (#5081) 2022-11-21 20:17:33 -06:00
laanwj
4fde6a8f71 Merge bitcoin/bitcoin#25436: build: GCC-12 build improvements
880d4aaf81f3d5d7fbb915905c2e61b816a6a747 build: use BOOST_NO_CXX98_FUNCTION_BASE to suppress warnings (fanquake)
1bdbbbdc46c4e50bf07bc362e7e391ea1a53ea2f build: suppress array-bounds errors in libxkbcommon (fanquake)

Pull request description:

  2 changes to better support building with GCC 12, which out of the box, is currently broken if you want to build using depends.
  Prevent `-Warray-bounds` errors when building libxkbcommon. i.e:
  ```bash
  src/xkbcomp/ast-build.c:82:27: error: array subscript 'ExprDef[0]' is partly outside array bounds of 'unsigned char[32]' [-Werror=array-bounds]
     82 |     expr->expr.value_type = type;
        |     ~~~~~~~~~~~~~~~~~~~~~~^~~~~~
  src/xkbcomp/ast-build.c:75:21: note: object of size 32 allocated by 'malloc'
     75 |     ExprDef *expr = malloc(size);
        |                     ^~~~~~~~~~~~
  ```

  It might be the case that these would be fixed by updating the
  package, but that would also require installing new build tools (meson),
  as well as potentially more dependencies (wayland), and it'd need
  testing with Qt. For now, just turn the errors into wanrings.

  Define `BOOST_NO_CXX98_FUNCTION_BASE` to prevent GCC warning about the use of `std::unary_function`. i.e:
  ```bash
  /bitcoin/depends/aarch64-unknown-linux-gnu/include/boost/container_hash/hash.hpp:131:33:
  warning: 'template<class _Arg, class _Result> struct std::unary_function' is deprecated [-Wdeprecated-declarations]
    131 |         struct hash_base : std::unary_function<T, std::size_t> {};
        |                                 ^~~~~~~~~~~~~~
  In file included from /usr/include/c++/12/bits/unique_ptr.h:37,
                   from /usr/include/c++/12/memory:76,
                   from ./init.h:10,
                   from init.cpp:10:
  /usr/include/c++/12/bits/stl_function.h:117:12: note: declared here
    117 |     struct unary_function
  ```

  Boost `container_hash` (included via functional -> multi_index) uses
  [`std::unary_function`, which was deprecated in C++11](https://en.cppreference.com/w/cpp/utility/functional/unary_function), and "removed" in
  C++17. It's use causes warnings with newer compilers, i.e GCC 12.1.

  Use the MACRO outlined in https://github.com/boostorg/container_hash/issues/22, and added to Boost Config for GCC 12 in https://github.com/boostorg/config/pull/430, to prevent it's use.

  [BOOST_NO_CXX98_FUNCTION_BASE](https://www.boost.org/doc/libs/master/libs/config/doc/html/boost_config/boost_macro_reference.html):
  > The standard library no longer supports std::unary_function and std::binary_function.
  > They were deprecated in C++11 and is removed from C++14.

  Guix Build (x86_64):
  ```bash

  ```

  Guix Build (arm64):
  ```bash

  ```

ACKs for top commit:
  laanwj:
    Code review ACK 880d4aaf81f3d5d7fbb915905c2e61b816a6a747

Tree-SHA512: 10c4679c3eb788e9279acc4960731c55ae1568bd3df525d3c46f97d8b0319e7d8450b1638b6777d98111b5991dba5c787e95d80b1ac932e0b4779d4b8e74875e
2022-11-02 10:24:45 -05:00
Kittywhiskers Van Gogh
6851dbf908 merge bitcoin#21882: Fix undefined reference to __mulodi4 2022-10-20 16:08:45 -05:00
PastaPastaPasta
0a61b95d44
chore: bump version to 18.2.0 (#5048) 2022-10-17 23:59:08 +03:00
UdjinM6
95194d28e9
Merge pull request #4896 from Munkybooty/backports-0.20-pr6
Backports 0.20 pr6
2022-10-13 02:37:00 +03:00
fanquake
e73d290cf0 Merge #17740: build: remove configure checks for win libraries we don't link against
2525c096b002a89d4c561e1474800496ad8ebd7e build: remove configure checks for win libraries we don't link against (fanquake)

Pull request description:

  While cross compiling, `HOST=x86_64-w64-mingw32`, none of these libs actually seem to be passed to the linker. i.e tailing a build with `make -j5 V=1 | rg -i 'mingwthrd|winspool|rpcrt4|crypt32'`.

  I'm not 100% sure about `crypt32`, even though the majority of our Windows cryptography usage, i.e [`CryptAcquireContextW`](https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecontextw) or [`CryptGenRandom`](https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom) is provided by `advapi32`.

  Note that `rpcrt4` and `mingwthrd` are already missing from the MSVC build, so we can sync the remainder once it's clear what's actually needed. Hopefully sipsorcery can add some MSVC insight.

ACKs for top commit:
  practicalswift:
    ACK 2525c096b002a89d4c561e1474800496ad8ebd7e -- diff looks correct
  sipsorcery:
    ACK 2525c096b002a89d4c561e1474800496ad8ebd7e.

Tree-SHA512: c756618f85ce2ab1e14e5514dbdc490d94c1c6dfd7a3e3d3b16344ae302fb789585dd10b5c2d784f961f3115bec1d914615051b3184bea00dfbcc3c23884ab4a
2022-10-03 16:08:31 -04:00
Kittywhiskers Van Gogh
c52700f2ef merge bitcoin#20560: Link all targets once 2022-10-02 12:05:30 +05:30
fanquake
2966452a1b
Merge #21486: build: link against -lsocket if required for *ifaddrs
4783115fd4cccb46a7f8c592b34fa7c094c29410 net: add ifaddrs.h include (fanquake)
879215e665a9f348c8d3fa92701c34065bc86a69 build: check if -lsocket is required with *ifaddrs (fanquake)
87deac66aa747481e6f34fc80599e1e490de3ea0 rand: only try and use freeifaddrs if available (fanquake)

Pull request description:

  Fixes #21485 by linking against `-lsocket` when it's required for using `*ifaddrs` functions.

ACKs for top commit:
  laanwj:
    Code review ACK 4783115fd4cccb46a7f8c592b34fa7c094c29410
  hebasto:
    ACK 4783115fd4cccb46a7f8c592b34fa7c094c29410, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: 4542e036e9b029de970eff8a9230fe45d9204bb22313d075f474295d49bdaf1f1cbb36c0c6e2fa8dbbcdba518d8d3a68a6116ce304b82414315f333baf9af0e4
2022-09-03 10:43:15 -05:00
Kittywhiskers Van Gogh
1e9733f195 merge bitcoin#19558: split pthread flags out of ldflags and dont use when building libconsensus 2022-08-23 21:33:33 +05:30
Kittywhiskers Van Gogh
f02085e988 revert dash#1432: Rename consensus source library and API
It's a shared library, so we should keep its name and API 
distinguishable from Bitcoin's and avoid pkgconfig confusion

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2022-08-09 14:16:28 +05:30
Kittywhiskers Van Gogh
c587212f8c partial revert dash#2911: s/dash-config/bitcoin-config/g 2022-08-09 14:16:28 +05:30
Kittywhiskers Van Gogh
ece4e1ee87 partial revert dash#3036: s/libbitcoin/libdash/g 2022-08-09 14:16:28 +05:30
Konstantin Akimov
a6e9e50845
Merge bitcoin/bitcoin#23315: [22.x] build: explicitly disable libsecp256k1 openssl based tests (#4941)
e959b46aa933856e7636557f4ec6fce0efbc76aa build: explicitly disable libsecp256k1 openssl based tests (fanquake)

Pull request description:

  Backport of #23314

  These tests are failing when run against OpenSSL 3, and have been
  removed upstream, bitcoin-core/secp256k1#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.

Top commit has no ACKs.

Tree-SHA512: ab3213dc82e7a64a005ce237710009bb447dee2702c4c02245e70df62063a00add73c4e80e9c619ce57345d4a2808fd4dc08e2e02a319b0f3d9285b8b0056599

Co-authored-by: MarcoFalke <falke.marco@gmail.com>
2022-07-27 21:25:14 +03:00
Kittywhiskers Van Gogh
959518fdfd merge bitcoin#18862: Remove fdelt_chk back-compat code and sanity check 2022-07-01 09:02:38 +05:30
fanquake
c1969bb2e8
Merge bitcoin/bitcoin#21788: build: Silence [-Wunused-command-line-argument] 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
2022-06-27 11:37:03 -05:00
fanquake
b2df26bec3
Merge #21421: build: don't try and use -fstack-clash-protection on Windows
7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8 build: don't try and use -fstack-clash-protection on Windows (fanquake)

Pull request description:

  This has never worked with any of the mingw-w64 compilers we use, and the `-O0` is causing issues for builders applying spectre mitigations (see [IRC logs](http://www.erisian.com.au/bitcoin-core-dev/log-2021-03-12.html#l-15)).

  Recent discussion on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 would also indicate that this should just not be used on Windows.

ACKs for top commit:
  laanwj:
    Concept and code review ACK (but untested) 7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8
  hebasto:
    ACK 7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8, I've verified that this change does not affect builds for `HOST=x86_64-w64-mingw32` by comparing sizes of the output `*.exe` files.

Tree-SHA512: 72b582321ddff8db3201460fa42a53304e70f141ae078d76a4d4eeb1ca27c8dd567ccb468cc8616179c8df784bd8ca038dcb9a277f9e29f9d98c3cc842916b18
2022-06-27 11:37:02 -05:00
fanquake
b50457044c
Merge #20720: build: more robustly check for fcf-protection support
e9189a750b237eba1befc6b16c12c2cee3e0176c build: more robustly check for fcf-protection support (fanquake)

Pull request description:

  When using Clang 7, we may end up trying to use the flag when it won't
  work properly, which can lead to confusing errors. i.e:
  ```bash
  /usr/bin/ld: error: ... <corrupt x86 feature size: 0x8>
  ```

  Use `AX_CHECK_LINK_FLAG` & `--fatal-warnings` to ensure we wont use the flag in this case.

  We do this as even when the error is emitted, compilation succeeds, and the binaries produced will run. This means we can't just check if the compiler accepts the flag, or if compilation succeeds (without or without `-Werror`, and/or passing `-Wl,--fatal-warnings`, which may not be passed through to the linker).

  This was reported by someone configuring for fuzzing, on Debian 10, where Clang 7 is the default.

  See here for a minimal example of the problematic behaviour:
  https://gist.github.com/fanquake/9b33555fcfebef8eb8c0795a71732bc6

ACKs for top commit:
  pstratem:
    tested ACK e9189a750b237eba1befc6b16c12c2cee3e0176c
  MarcoFalke:
    not an ACK e9189a750b237eba1befc6b16c12c2cee3e0176c , I only tested configure on my system (gcc-10, clang-11):
  hebasto:
    ACK e9189a750b237eba1befc6b16c12c2cee3e0176c, tested with clang-7, clang-10 and gcc: the `-fcf-protection=full` is not applied for clang-7, but applied for others compilers.

Tree-SHA512: ec24b0cc5523b90139c96cbb33bb98d1e6a24d858c466aa7dfb3c474caf8c50aca53e570fdbc0ff88378406b0ac5d687542452637b1b5fa062e829291b886fc1
2022-06-18 22:14:04 -07:00
Jonas Schnelli
2622653e74
Merge #20563: build: Check that Homebrew's berkeley-db4 package is actually installed
d3ef947524a07f8d7fbad5b95781ab6cacb1cb49 build: Check that Homebrew's berkeley-db4 package is actually installed (Hennadii Stepanov)

Pull request description:

  On master (a0489f3472f3799dc1ece32a59556fd239c4c14b) the `configure` script is not able to determine that Homebrew's `berkeley-db4` package is uninstalled. This causes a compile error on macOS.

  With this PR, and with the [uninstalled](https://stackoverflow.com/questions/20802320/detect-if-homebrew-package-is-installed) `berkeley-db4` package:
  ```
  % ./configure -q
  configure: error: libdb_cxx headers missing, Bitcoin Core requires this library for BDB wallet support (--without-bdb to disable BDB wallet support)
  ```

  Related #20478.

ACKs for top commit:
  promag:
    Tested ACK d3ef947524a07f8d7fbad5b95781ab6cacb1cb49.
  willcl-ark:
    tACK d3ef947524a07f8d7fbad5b95781ab6cacb1cb49
  jonasschnelli:
    utACK d3ef947524a07f8d7fbad5b95781ab6cacb1cb49

Tree-SHA512: 8dc532e08249ec63bd357594aa458d314b6e8537fc63f5b1d509c84d0d71d5b1f70172caa1a7efe2fc8af31c829e7982a0695cf3fbe5cbc477019550269915e1
2022-06-18 22:14:04 -07:00
Jonas Schnelli
6d5109e90f
Merge #20478: Don't set BDB flags when configuring without
982e548a9a78b1b0abad59b54c780b6b06570452 Don't set BDB flags when configuring without (Jonas Schnelli)

Pull request description:

  Configuring `--without-bdb` on MacOS leads to a compile error (when BerkeleyDB is not installed). `brew --prefix berkeley-db4` always reports the target directory (even if not installed).

  This PR prevents BDB_CFLAGS (et al) from being populated when configuring `--without-bdb`

  ```
  ld: warning: directory not found for option '-L/Users/user/Documents/homebrew/Cellar/berkeley-db@4/4.8.30/lib'
  ld: warning: directory not found for option '-L/Users/user/Documents/homebrew/Cellar/berkeley-db@4/4.8.30/lib'
  ld: library not found for -ldb_cxx-4.8
  ld: library not found for -ldb_cxx-4.8
  ```

ACKs for top commit:
  promag:
    Tested ACK 982e548a9a78b1b0abad59b54c780b6b06570452.
  hebasto:
    ACK 982e548a9a78b1b0abad59b54c780b6b06570452, tested on macOS 11 Big Sur.

Tree-SHA512: f8ca0adca0e18e2de4c0f99d5332cba70d957a9d31a357483b43dcf61c2ed4749d223eabadd45fdbf3ef0781c6b37217770e9aa935b5207eaf7f87c5bdfe9e95
2022-06-18 22:14:04 -07:00
Wladimir J. van der Laan
e1b091be3b
Merge #18921: build: add stack-clash and control-flow protection options to hardening flags
b536813cefc13f5c54a28a7c2fce8c69e89d6624 build: add -fstack-clash-protection to hardening flags (fanquake)
076183b36b76a11438463883ff916f17aef9e001 build: add -fcf-protection=full to hardening options (fanquake)

Pull request description:

  Beginning with Ubuntu `19.10`, it's packaged GCC now has some additional hardening options enabled by default (in addition to existing defaults like `-fstack-protector-strong` and reducing the minimum ssp buffer size). The new additions are`-fcf-protection=full` and `-fstack-clash-protection`.

  > -fcf-protection=[full|branch|return|none]
  > Enable code instrumentation of control-flow transfers to increase program security by checking that target addresses of control-flow transfer instructions (such as indirect function call, function return, indirect jump) are valid. This prevents diverting the flow of control to an unexpected target. This is intended to protect against such threats as Return-oriented Programming (ROP), and similarly call/jmp-oriented programming (COP/JOP).

  > -fstack-clash-protection
  > Generate code to prevent stack clash style attacks. When this option is enabled, the compiler will only allocate one page of stack space at a time and each page is accessed immediately after allocation. Thus, it prevents allocations from jumping over any stack guard page provided by the operating system.

  If your interested you can grab `gcc-9_9.3.0-10ubuntu2.debian.tar.xz` from https://packages.ubuntu.com/focal/g++-9. The relevant changes are part of the `gcc-distro-specs` patches, along with the relevant additions to the gcc manages:

  > NOTE: In Ubuntu 19.10 and later versions, -fcf-protection is enabled by default for C, C++, ObjC, ObjC++, if none of -fno-cf-protection nor -fcf-protection=* are found.

  > NOTE: In Ubuntu 19.10 and later versions, -fstack-clash-protection is enabled by default for C, C++, ObjC, ObjC++, unless -fno-stack-clash-protection is found.

  So, if you're C++ using GCC on Ubuntu 19.10 or later, these options will be active unless you explicitly opt out. This can be observed with a small test:

  ```c++
  int main() { return 0; }
  ```

  ```bash
  g++ --version
  g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0

  g++ test.cpp

  objdump -dC a.out
  ..
  0000000000001129 <main>:
      1129:	f3 0f 1e fa          	endbr64
      112d:	55                   	push   %rbp
      112e:	48 89 e5             	mov    %rsp,%rbp
      1131:	b8 00 00 00 00       	mov    $0x0,%eax
      1136:	5d                   	pop    %rbp
      1137:	c3                   	retq
      1138:	0f 1f 84 00 00 00 00 	nopl   0x0(%rax,%rax,1)
      113f:	00

  # recompile opting out of control flow protection
  g++ test.cpp -fcf-protection=none

  objdump -dC a.out
  ...
  0000000000001129 <main>:
      1129:	55                   	push   %rbp
      112a:	48 89 e5             	mov    %rsp,%rbp
      112d:	b8 00 00 00 00       	mov    $0x0,%eax
      1132:	5d                   	pop    %rbp
      1133:	c3                   	retq
      1134:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
      113b:	00 00 00
      113e:	66 90                	xchg   %ax,%ax
  ```

  Note the insertion of an `endbr64` instruction when compiling and _not_ opting out. This instruction is part of the Intel Control-flow Enforcement Technology [spec](https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf), which the GCC control flow implementation is based on.

  If we're still doing gitian builds for the `0.21.0` and `0.22.0` releases, we'd likely update the gitian image to Ubuntu Focal, which would mean that the GCC used for gitian builds would also be using these options by default. So we should decide whether we want to explicitly turn these options on as part of our hardening options (although not just for this reason), or, we should be opting-out.

  GCC has supported both options since 8.0.0. Clang has supported `-fcf-protection` from 7.0.0 and will support `-fstack-clash-protection` in it's upcoming [11.0.0 release](https://clang.llvm.org/docs/ReleaseNotes.html#id6).

ACKs for top commit:
  jamesob:
    ACK b536813cefc13f5c54a28a7c2fce8c69e89d6624 ([`jamesob/ackr/18921.1.fanquake.build_add_stack_clash_an`](https://github.com/jamesob/bitcoin/tree/ackr/18921.1.fanquake.build_add_stack_clash_an))
  laanwj:
    Code review ACK b536813cefc13f5c54a28a7c2fce8c69e89d6624

Tree-SHA512: abc9adf23cdf1be384f5fb9aa5bfffdda86b9ecd671064298d4cda0440828b509f070f9b19c88c7ce50ead9ff32afff9f14c5e78d75f01241568fbfa077be0b7
2022-06-18 22:14:03 -07:00
fanquake
37d58e402c
Merge #19356: build: Fix search for brew-installed BDB 4 on OS X
8578c6fccd11404412d2c60f9bede311b79ca0d0 build: Fix search for brew-installed BDB 4 on OS X (Glenn Willen)

Pull request description:

  ~~NOTE: This PR contains one important fix that I need (to make Bitcoin Core build cleanly on my system without shenanigans), plus some related general cleanup that is not really necessary, and could be annoying. (I am prepared to defend my argument that BDB_CFLAGS is wrong here, and BDB_CPPFLAGS is right, but this could bite anybody who has gotten in the habit of -- or scripted -- setting the former.)~~

  Ok, I have been convinced that I was too clever with the refactor and I have removed it. Now it's just the tiny change to fix the build on my local machine.

  ---

  On OS X, when searching Homebrew keg-only packages for BDB 4.8, if we find it,
  use BDB_CPPFLAGS and BDB_LIBS instead of CFLAGS and LIBS for the result. This
  is (1) more correct, and (2) necessary in order to give this location
  priority over other directories in the include search path, which may include
  system include directories with other versions of BDB.

ACKs for top commit:
  theuni:
    ACK 8578c6fccd11404412d2c60f9bede311b79ca0d0.

Tree-SHA512: a28f48fc81a25736f7e77c663f21cd9a6ae1cd115682031c5aa695c94cb5afa11920330a60cd6a54832822a2aec1eb23123ac2e2dcd4f0b3835aef9c9339ac97
2022-06-18 22:14:03 -07:00
fanquake
96866c4579
Merge #18709: doc: note why we can't use thread_local with glibc back compat
b155fcda5186c59fc4fb2a9eaaf791d132e0ab30 doc: fix typo in configure.ac (fanquake)
20a30922fbf6ba14e250ca649239af115dbbe7b0 doc: note why we can't use thread_local with glibc back compat (fanquake)

Pull request description:

  Given that we went through a [gitian build](https://github.com/bitcoin/bitcoin/pull/18681) to remember why this is the case, we might as well make a note of it in configure.ac.

  [From #18681](https://github.com/bitcoin/bitcoin/pull/18681#issuecomment-615526634):

  Looking at the Linux build log, this has failed with:
  ```bash
  Checking glibc back compat...
  bitcoind: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
  bitcoind: failed IMPORTED_SYMBOLS
  bitcoin-cli: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
  bitcoin-cli: failed IMPORTED_SYMBOLS
  bitcoin-tx: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
  bitcoin-tx: failed IMPORTED_SYMBOLS
  bitcoin-wallet: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
  bitcoin-wallet: failed IMPORTED_SYMBOLS
  test/test_bitcoin: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
  test/test_bitcoin: failed IMPORTED_SYMBOLS
  bench/bench_bitcoin: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
  bench/bench_bitcoin: failed IMPORTED_SYMBOLS
  qt/bitcoin-qt: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
  ```

  `__cxa_thread_atexit_impl` is used for [thread_local variable destruction](https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables):

  > To implement this support, glibc defines __cxa_thread_atexit_impl exclusively for use by libstdc++ (which has the __cxa_thread_atexit to wrap around it), that registers destructors for thread_local variables in a list. Upon thread or process exit, the destructors are called in reverse order in which they were added.

  As suggested, this only became available in glibc 2.18. From the [2.18 release notes](https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html):

  > * Add support for calling C++11 thread_local object destructors on thread
    and program exit.  This needs compiler support for offloading C++11
    destructor calls to glibc.

ACKs for top commit:
  hebasto:
    ACK b155fcda5186c59fc4fb2a9eaaf791d132e0ab30

Tree-SHA512: 5b9567e4a70598a4b0b91956f44ae0d93091db17c84cbf9817dac6cfa992c97d3438a8b1bb66644c74891f2149e44984daed445d22de93ca8858c5b0eabefb40
2022-06-18 22:14:02 -07:00
Wladimir J. van der Laan
3ceb45fdb7
Merge #18135: build: add --enable-determinism configure flag
3d9b41ecc02a69daa19df2bc850d60bf9917b724 build: add --enable-determinism configure flag (fanquake)

Pull request description:

  This adds a `--enable-determinsm` configure flag, which if used, will enable additional compile / link time flags to make subsequent builds of bitcoind deterministic.

  The first flag enabled is `--no-insert-timestamp`. This prevents the linker from embedding timestamps, and makes consecutive builds of `bitcoind.exe` deterministic. This will likely also be used for [Guix Windows builds](https://github.com/bitcoin/bitcoin/pull/17595#issuecomment-582696467).

  [`--no-insert-timestamp`](https://manpages.debian.org/buster/binutils-mingw-w64-x86-64/x86_64-w64-mingw32-ld.bfd.1.en.html):
  > The option --no-insert-timestamp can be used to insert a zero value for the timestamp, this ensuring that binaries produced from identical sources will compare identically.

  Diff of consecutive builds of [master](2bdc476d4d):
  ```diff
  --- bitcoind.exe.1
  +++ bitcoind.exe.2
  @@ -2,20 +2,20 @@
   00000060: 7420 6265 2072 756e 2069 6e20 444f 5320  t be run in DOS
   00000070: 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000  mode....$.......
  -00000080: 5045 0000 6486 1400 57e8 445e 00da 6900  PE..d...W.D^..i.
  +00000080: 5045 0000 6486 1400 e3e9 445e 00da 6900  PE..d.....D^..i.
   00000090: e015 0100 f000 2600 0b02 021f 00de 4900  ......&.......I.
   000000a0: 00b0 5b00 008a 0000 e014 0000 0010 0000  ..[.............
   000000b0: 0000 4000 0000 0000 0010 0000 0002 0000  ..@.............
   000000c0: 0400 0000 0000 0000 0500 0200 0000 0000  ................
  -000000d0: 00f0 6a00 0006 0000 bd31 af00 0300 6001  ..j......1....`.
  +000000d0: 00f0 6a00 0006 0000 d434 af00 0300 6001  ..j......4....`.
   000000e0: 0000 2000 0000 0000 0010 0000 0000 0000  .. .............
  @@ -373594,15 +373594,15 @@
   005b35f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  -005b3600: 0000 0000 57e8 445e 0000 0000 7ce1 5b00  ....W.D^....|.[.
  +005b3600: 0000 0000 e2e9 445e 0000 0000 7ce1 5b00  ......D^....|.[.
   005b3610: 0100 0000 2200 0000 2200 0000 28e0 5b00  ...."..."...(.[.
  ```

ACKs for top commit:
  practicalswift:
    ACK 3d9b41ecc02a69daa19df2bc850d60bf9917b724 -- patch looks correct
  laanwj:
    ACK 3d9b41ecc02a69daa19df2bc850d60bf9917b724

Tree-SHA512: 1ff9dab7fa818b1fc6b0eb3b7a1e0468aac9e2578f4451aa300a648f883fa83f83722067f1adf27ebad54157790857d1501d573adbd7ebdf6962858cc669960d
2022-06-18 22:14:02 -07:00
Wladimir J. van der Laan
091865b02c
Merge #18082: logging: enable thread_local usage on macOS
d76894987d0277e8011932ab7dfd77c537f8ea6e logging: enable thread_local usage on macOS (fanquake)

Pull request description:

  Now that we're building against a newer SDK (`10.14`), we should be able to enable `thread_local` usage on macOS. Have tested building and running locally, as well as cross-compiling and running the binaries on a macOS 10.14 system.

  #### master 8a56f79d491271120abc3843c46e9dda44edd308
  ```bash
  src/bitcoind -logthreadnames=1
  2020-02-06T04:38:33Z [] Bitcoin Core version v0.19.99.0-8a56f79d4 (release build)
  2020-02-06T04:38:33Z [] Assuming ancestors of block 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf have valid signatures.
  2020-02-06T04:38:33Z [] Setting nMinimumChainWork=000000000000000000000000000000000000000008ea3cf107ae0dec57f03fe8
  2020-02-06T04:38:33Z [] Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
  2020-02-06T04:38:33Z [] Using RdSeed as additional entropy source
  ```

  #### this PR d76894987d0277e8011932ab7dfd77c537f8ea6e
  ```bash
  checking for thread_local support... yes
  ...
  src/bitcoind -logthreadnames=1
  2020-02-06T04:17:49Z [net] net thread start
  2020-02-06T04:17:49Z [opencon] opencon thread start
  2020-02-06T04:17:49Z [dnsseed] dnsseed thread start
  2020-02-06T04:17:49Z [init] init message: Done loading
  2020-02-06T04:17:49Z [msghand] msghand thread start
  2020-02-06T04:17:49Z [addcon] addcon thread start
  ...
  2020-02-06T04:17:54Z [init] tor: Thread interrupt
  2020-02-06T04:17:54Z [init] Shutdown: In progress...
  ```

  From the [Xcode 8 release notes](https://developer.apple.com/library/archive/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW78)
  > C++ now supports the thread_local keyword, which declares thread-local storage (TLS) and supports C++ classes with non-trivial constructors and destructors. (9001553)

ACKs for top commit:
  jonasschnelli:
    Tested ACK d76894987d0277e8011932ab7dfd77c537f8ea6e
  nijynot:
    ACK d768949
  hebasto:
    ACK d76894987d0277e8011932ab7dfd77c537f8ea6e

Tree-SHA512: 48f3e4104b80bd7b6aedcef10bb1957b073530130f33af7c5cb59e876ac3f5480e53d7af1c0b226d809fe9eef1add3d6c3fb6de4af174966202c6030060ea823
2022-06-18 22:14:01 -07:00
MarcoFalke
59c55fd274 Merge #17703: build: Improve configure.ac formatting
3ab18246254019896132d1cdb8af2dcdb213ec3b build: Use dnl for all comments in configure.ac, rather than # (fanquake)
8ddcbb4e41fa91e7f80efe6d9c4d5e9bb1355036 build: Remove backticks from configure.ac (fanquake)

Pull request description:

  Use `dnl` for all comments, rather than `#`.
  Remove backticks - Their usage for the `bdb_prefix` and `qt5_prefix` commands may have improved backwards compatibility in some cases, however we now require recent versions of macOS. I'm not sure why they were being used in the `HAVE_STD__SYSTEM` and `HAVE_WSYSTEM` defines.

ACKs for top commit:
  dongcarl:
    ACK 3ab18246254019896132d1cdb8af2dcdb213ec3b
  hebasto:
    ACK 3ab18246254019896132d1cdb8af2dcdb213ec3b, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: 2bcffb52c365acff87a0e6b9527ae31f36fdabb7ea095a8fd261f9a39b2c2848f5dfc148bc38d21e21e7bd761b1a2960e9a96f508c66be84d9569b8a401e812a
2022-06-08 12:33:00 +07:00
PastaPastaPasta
d64b7229cd
chore: bump copyrights (#4873)
* chore: bump copyright in configure.ac

* chore: bump copyright via copyright_header.py

ran command `python3 contrib/devtools/copyright_header.py update .`
2022-06-08 02:36:46 +03:00
fanquake
3dbbdf6775
Merge #19719: build: Add Werror=range-loop-analysis
fa55c1d5fdd88c4bc4d361da231cd63b20255b50 build: Add Werror=range-loop-analysis (MarcoFalke)

Pull request description:

  The warning is implicitly enabled for Bitcoin Core. Also explicitly since commit d92204c900d.

  To avoid "fix range loop" follow-up refactors, we have two options:

  * Disable the warning, so that issues never appear
  * Enable it as an error, so that issues are either caught locally or by ci

ACKs for top commit:
  fanquake:
    ACK fa55c1d5fdd88c4bc4d361da231cd63b20255b50
  practicalswift:
    ACK fa55c1d5fdd88c4bc4d361da231cd63b20255b50 -- pre-review fix-up is better than post-review fix-up
  hebasto:
    re-ACK fa55c1d5fdd88c4bc4d361da231cd63b20255b50

Tree-SHA512: 019aa133f254af8882c1d5d10c420d9882305db0fc2aa9dad7d285168e2556306c3eedcc03bd30e63f11eae4cc82b648d83fb6e9179d6a6364651fb602d70134
2022-06-07 16:11:23 -05:00
Kittywhiskers Van Gogh
6627bc9688 merge bitcoin#15457: Check std::system for -[alert|block|wallet|instantsend]notify 2022-06-07 09:21:28 +05:30
Kittywhiskers Van Gogh
63b9860cf2 merge bitcoin#19188: Avoid overwriting the NodeContext member of the testing setup [-Wshadow-field]
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2022-06-03 18:25:28 +05:30
Kittywhiskers Van Gogh
6d8839473c merge bitcoin#20255: Add Assume() identity function 2022-05-13 18:06:06 +05:30
Kittywhiskers Van Gogh
b47d4843bf
merge bitcoin#22646: tighter Univalue integration, remove --with-system-univalue (#4823)
* merge bitcoin#22646: tighter Univalue integration, remove `--with-system-univalue`

* masternode: add missing header in meta.cpp
2022-05-02 10:31:46 -05:00
UdjinM6
208fa62acb
Merge pull request #4818 from PastaPastaPasta/develop-trivial-2022-04-28
backport trivial 2022 04 28
2022-04-28 23:24:27 +03:00
MarcoFalke
0277d06767 Merge bitcoin/bitcoin#23761: build: use __SIZEOF_INT128__ for checking __int128 availability
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
2022-04-28 10:59:05 -05:00
UdjinM6
b22d589d4e
Merge pull request #4817 from UdjinM6/drop_0
build: switch to classical `major.minor.patch` semver
2022-04-28 18:40:08 +03:00
PastaPastaPasta
2197786843
Merge pull request #4704 from kittywhiskers/muhash
merge bitcoin#17319...19601: muhash implementation
2022-04-28 10:30:09 -05:00
PastaPastaPasta
f56b7fcf81
Merge pull request #4812 from Munkybooty/misc-backports
Misc backports v17
2022-04-28 10:13:43 -05:00
MarcoFalke
a3a7a22268
Merge #20223: build: Drop the leading 0 from the version number
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
2022-04-28 13:47:53 +03:00
UdjinM6
4d70755155 more of/followup 13177 2022-04-27 10:45:51 -04:00
Kittywhiskers Van Gogh
c7eb44a911 partial bitcoin#19055: Add MuHash3072 implementation
Excludes b111410914041b72961536c3e4037eba103a8085 and 01297fb3ca57e4b8cbc5a89fc7c6367de33b0bc6
2022-04-27 20:05:13 +05:30
PastaPastaPasta
1e3c35e6bd
chore: bump develop to 18.1.0.0 (#4811) 2022-04-26 21:03:29 +03:00
Wladimir J. van der Laan
87112fd95f Merge #13177: GCC-7 and glibc-2.27 back compat code
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
2022-04-26 13:41:49 -04:00
Pieter Wuille
3285e21cfd Merge #12686: Add -ftrapv to CFLAGS and CXXFLAGS when --enable-debug is used. Enable -ftrapv in Travis.
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
2022-04-26 13:16:11 -04:00