8bf1d06599 Merge bitcoin/bitcoin#29308: doc: update `BroadcastTransaction` comment (glozow)
2a77808596 Merge bitcoin-core/gui#789: Avoid non-self-contained Windows header (Hennadii Stepanov)
da371b830d Merge bitcoin/bitcoin#28870: depends: Include `config.guess` and `config.sub` into `meta_depends` (fanquake)
2e41562d81 Merge bitcoin/bitcoin#29219: fuzz: Improve fuzzing stability for ellswift_roundtrip harness (fanquake)
b091329599 Merge bitcoin/bitcoin#29211: fuzz: fix `connman` initialization (Ava Chow)
df42d41060 Merge bitcoin/bitcoin#29200: net: create I2P sessions using both ECIES-X25519 and ElGamal encryption (fanquake)
4cdd1a8a5d Merge bitcoin/bitcoin#29172: fuzz: set `nMaxOutboundLimit` in connman target (fanquake)
97012ea522 Merge bitcoin/bitcoin#28962: doc: Rework guix docs after 1.4 release (fanquake)
c70ff5d702 Merge bitcoin/bitcoin#28844: contrib: drop GCC MAX_VERSION to 4.3.0 in symbol-check (fanquake)
e6f19e7760 Merge bitcoin/bitcoin#29068: test: Actually fail when a python unit test fails (fanquake)
75e0334866 Merge bitcoin/bitcoin#28989: test: Fix test by checking the actual exception instance (Andrew Chow)
8cd85d311f Merge bitcoin/bitcoin#28852: script, assumeutxo: Enhance validations in utxo_snapshot.sh (Ryan Ofsky)
fd2e88d6f3 Merge bitcoin/bitcoin#26077: guix: switch from `guix environment` to `guix shell` (fanquake)
02741a7706 Merge bitcoin/bitcoin#28913: coins: make sure PoolAllocator uses the correct alignment (fanquake)
dfd53dabed Merge bitcoin/bitcoin#28902: doc: Simplify guix install doc, after 1.4 release (fanquake)
Pull request description:
## Issue being fixed or feature implemented
Batch of trivial backports
## What was done?
See commits
## How Has This Been Tested?
built locally; large combined merge passed tests locally
## Breaking Changes
Should be none
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK 8bf1d06599
knst:
utACK 8bf1d06599
Tree-SHA512: 506273e5a188f9ca74edf656e3cd338992192e6e97f68c89fc43e34be20fb7f211b48e4dfa8693727839a7920da8284509413c722f55774a428939c296dad517
05aca093819be276ac7d648472c6ed5c7d235cc5 build: Patch Qt to handle minimum macOS version properly (Hennadii Stepanov)
Pull request description:
This PR is:
- required to [switch](https://github.com/bitcoin/bitcoin/pull/28622) to macOS 14 SDK (Xcode 15).
- an alternative to https://github.com/bitcoin/bitcoin/pull/28732 and https://github.com/bitcoin/bitcoin/pull/28775.
Qt relies on the `__MAC_OS_X_VERSION_MIN_REQUIRED` macro, which is set in the `AvailabilityInternal.h` SDK header to
the value provided by the Clang driver from the `-mmacos-version-min` / `-mmacosx-version-min` option.
Xcode 12 SDK expects the OS-specific `__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__` macro:
```c++
#ifndef __MAC_OS_X_VERSION_MIN_REQUIRED
#ifdef __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
/* compiler for Mac OS X sets __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ */
#define __MAC_OS_X_VERSION_MIN_REQUIRED __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
#endif
#endif /* __MAC_OS_X_VERSION_MIN_REQUIRED*/
```
In the other hand, Xcode 15 SDK expects a general `__ENVIRONMENT_OS_VERSION_MIN_REQUIRED__` macro:
```c++
#ifndef __MAC_OS_X_VERSION_MIN_REQUIRED
#if defined(__has_builtin) && __has_builtin(__is_target_os)
#if __is_target_os(macos)
#define __MAC_OS_X_VERSION_MIN_REQUIRED __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__
#define __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_14_0
#endif
#elif __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
#define __MAC_OS_X_VERSION_MIN_REQUIRED __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
#define __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_14_0
#endif /* __has_builtin(__is_target_os) && __is_target_os(macos) */
#endif /* __MAC_OS_X_VERSION_MIN_REQUIRED */
```
The latter macro is not provided by LLVM Clang until c8e2dd8c6f, which is available in Clang 17.
The suggested patch makes Qt "borrow" the `__MAC_OS_X_VERSION_MIN_REQUIRED` value from `MAC_OS_X_VERSION_MIN_REQUIRED`, which is set in the `AvailabilityMacros.h` SDK header.
ACKs for top commit:
maflcko:
lgtm ACK 05aca093819be276ac7d648472c6ed5c7d235cc5
Tree-SHA512: 8891aefde4b8a48885abf0648f4ec71a22f7fcfca1e17ebb8c70ce1ef44751ea5db6b8b652de6ee8a716ca5f96f720fef01600bc23986162d0146c946e2e8743
821a8a11256ccf26fe8b0255cea4ec04dddd8f18 doc: remove x86_64 build assumption from depends doc (fanquake)
Pull request description:
This dates from the introduction of depends, and has not been the case for some time now.
ACKs for top commit:
maflcko:
lgtm ACK 821a8a11256ccf26fe8b0255cea4ec04dddd8f18
hebasto:
ACK 821a8a11256ccf26fe8b0255cea4ec04dddd8f18.
theuni:
ACK 821a8a11256ccf26fe8b0255cea4ec04dddd8f18
Tree-SHA512: 640967a3e6dfab495fd733d3379aa916ac7f67e89a92ef6a94c3bea0494dc7921a9d7485e1b90a1beab00548b575cdab8fb08eb9267dcc5e890cc796ae1b6875
f0cebbdb2a1a3c2f0facd88963484ad6fd5851db qt: enable -ltcg for windows HOST (fanquake)
Pull request description:
Patch around multiple definition issues in Qt, and enable `-ltcg` when using `LTO=1`.
Split from #25391.
ACKs for top commit:
hebasto:
ACK f0cebbdb2a1a3c2f0facd88963484ad6fd5851db
Tree-SHA512: 2d6e34779f360bf6dfea4f70fc9004a16e95da79716fcb3046afbf2b01317b7e16965cb51b967b7b5fb64549306c5f48cf59082884289c52016bc1e86949e062
0fbf051fec723f86f49ab14ea15c91bb1435c656 depends: fix BDB compilation on OpenBSD (Sebastian Falbesoner)
Pull request description:
Compiling C++ code with `-D_XOPEN_SOURCE=600` causes problems on OpenBSD. If that define is set, the C++ standard header detection routine in BDB's configure script fails due to a missing type name for `locale_t` (see https://gist.github.com/theStack/b41884e31ebc5cdca3220bcaa674cb70 for the relevant config.log part).
This results in `HAVE_CXX_STDHEADERS` not being defined, which then it turn leads to the inclusion of `<iostream.h>` (rather than `<iostream>`), which doesn't exist, as described in #28963.
According to a mailing list post discussing a similar problem [1], "OpenBSD provides the POSIX APIs by default", so we don't need this define anyway and can remove it. This fixes the BDB build problem as described in issue #28963. See also f87e75ae71 for a similar fix for google's flatbuffer project.
Tested on OpenBSD 7.4 with clang 13.0.0. Fixes#28963.
[1] https://www.mail-archive.com/tech@openbsd.org/msg63386.html
ACKs for top commit:
fanquake:
ACK 0fbf051fec723f86f49ab14ea15c91bb1435c656
Tree-SHA512: 02139e9081ed855e067bfba8c81b54c657417576e553cc1035a916ada9be049358f5e14d756d5f234c5226bd7e943f61c6ae8990c1b152f9125681b7b777c9b3
ff3f51b402efe6dc0b4bd14aecb9b58c2815c6e4 depends: Include `config.guess` and `config.sub` into `meta_depends` (Hennadii Stepanov)
Pull request description:
ACKs for top commit:
theuni:
ACK ff3f51b402efe6dc0b4bd14aecb9b58c2815c6e4.
Tree-SHA512: e8575473d3fca2293181131c76bd6d43017fe753d2e670c53227a646b64b069dc542a0fc50a77b43e74bc6a0c0159ffa2fb1c3ff3aef9625684e0f78c16ad960
9ae854da193f3c4bda38a75e96f9b989b289baab depends: no-longer nuke libc++abi.so* in native_clang package (fanquake)
Pull request description:
We weren't copying it over in any case.
ACKs for top commit:
hebasto:
ACK 9ae854da193f3c4bda38a75e96f9b989b289baab
theuni:
Sure. utACK no-op 9ae854da193f3c4bda38a75e96f9b989b289baab.
Tree-SHA512: 3cc7f18f27c1b498f930bc1a09283aa04ba673d3c1a5220d8462213f0a06b74bc34989f23404402850de518cba35ddab900a54f7f0fac112fc86664e4155f8cb
bc4fd49d09dec3791b0acd4ada285b2287361d14 depends: add _LIBCPP_ENABLE_ASSERTIONS to DEBUG mode (fanquake)
cf266b2270081f05a277ba683f00de90a741112f depends: Remove _LIBCPP_DEBUG from depends DEBUG mode (fanquake)
Pull request description:
It was deprecated in LLVM 15, turned into compile-time error in LLVM 16:
```bash
In file included from /usr/lib/llvm-16/bin/../include/c++/v1/cassert:19:
/usr/lib/llvm-16/bin/../include/c++/v1/__assert:22:5: error: "Defining _LIBCPP_DEBUG is not supported anymore.
Please use _LIBCPP_ENABLE_DEBUG_MODE instead."
^
1 error generated.
```
and has been removed entirely in LLVM 17 (main): ff573a42cd.
[Building libc++ in debug mode](https://releases.llvm.org/16.0.0/projects/libcxx/docs/DesignDocs/DebugMode.html), will also automatically set
`_LIBCPP_ENABLE_DEBUG_MODE` (the new define), so adding it to depends
doesn't seem useful, and would just result in redefinition errors.
I'm wondering if as a followup, we could enable a DEBUG build of libc++
in our MSAN CI job? i.e https://github.com/fanquake/bitcoin/tree/msan_with_enable_debug_mode.
Somewhat related to https://github.com/google/oss-fuzz/pull/9828, where
it looks like we'll have to sort out getting a DEBUG build of LLVM, and can drop the commentary about re-enabling DEBUG=1.
ACKs for top commit:
MarcoFalke:
lgtm Approach ACK bc4fd49d09dec3791b0acd4ada285b2287361d14
Tree-SHA512: 9c0f48fc428278fbf34fbb8f81e761e232506d7ab28e971cb9a9b9a81d549b4d8bbe51e2f7608d56e489428679231da5b7431443849b238a8a993ad241740282
9cbc1c279247800d79c5f6f95c0c2d8f387aac0a depends: make fontconfig build under clang-16 (fanquake)
Pull request description:
Use the same workaround we've applied to qrencode, and other packages. Fontconfig not building is currently a blocker for fuzz/sanitizer infra upgrades (#27298).
For now, this is also more straightforward than bumping the package, which introduces more complexity/usage of gperf.
Closes: #27299.
ACKs for top commit:
hebasto:
ACK 9cbc1c279247800d79c5f6f95c0c2d8f387aac0a
Tree-SHA512: 387ea1a73e3429f166ef5278305a56cb3c69b6e3fc8a21a66521738e313e3fe783f042759b396cd88e28c10918a4427fb836a8dfecc5a846723b6f6c6a7ade51
87afcb0029b8dab933c122fb8f7263c2e7272731 depends: fix osx build with clang 16 (Cory Fields)
Pull request description:
Current build (using forced system clang as a test) results in:
> error: unknown argument: '-internal-externc-isystem/opt/clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/include'
For some reason the previous syntax worked with clang 15 and below, but clang 16 requires that the option and value are properly separated.
See [here for an example of upstream using this syntax](https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/crash-report-with-asserts.c#L9).
There is no change in behavior for previous versions.
I'm seeing an additional unrelated problem with linking with system clang, but I'll PR the solution to that separately as it's not as straightforward as this.
ACKs for top commit:
TheCharlatan:
ACK 87afcb0029b8dab933c122fb8f7263c2e7272731
hebasto:
ACK 87afcb0029b8dab933c122fb8f7263c2e7272731
Tree-SHA512: 127037c888c37c6ccd9679e96da34037cc43ccdc07915865a0a5494edb62633e83fc1bd6b1c4bb7a0322f5b59622e10090a31987f38496fb6b306488e9941594
76045bb9d6808931cd0f2933203b5b611e032ec8 depends: always set CMAKE_POSITION_INDEPENDENT_CODE=ON (fanquake)
d04623678c70ff58a20fb5c35d33cb8f483f1efb depends: always set CMAKE_INSTALL_LIBDIR=lib/ (fanquake)
Pull request description:
Set `CMAKE_INSTALL_LIBDIR=lib/` and `CMAKE_POSITION_INDEPENDENT_CODE=ON` globally in depends, rather than per-package. `CMAKE_INSTALL_LIBDIR=lib/` is needed to override the annoying [`GNUInstallDirs`](https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html) `lib` vs `lib64` behaviour, and we always want PIC code. The PIC commit is the counterpart to the same Autotools change in #29488. I'm PRing these commits as I have a CMake branch building on top, and want to avoid adding the same workarounds to every package we are going to touch, but these can go in separately as the build should be tested for existing packages (i.e multiprocess).
ACKs for top commit:
hebasto:
re-ACK 76045bb9d6808931cd0f2933203b5b611e032ec8.
theuni:
utACK 76045bb9d6808931cd0f2933203b5b611e032ec8. Both changes make sense to me, and both can be overridden if needed, though I can't imagine we'd need to.
Tree-SHA512: 655a0b6b7ee5a5820f52e8e919ef03fc216d29f13f3904f72b64ce57436510e073c903039488d5740535c56e1f6221267229238c5231de5f8467d238fd562578
bde8d63b17637c507a543cebe90f2998b5847373 depends: build libmultiprocess with position independant code (fanquake)
506634d79d6427925cd458f67799fe59e0ab14dd depends: always install libmultiprocess to /lib (fanquake)
beb309626381bf189cd2ae8bde83078b9de47c6a depends: always install capnp to /lib (fanquake)
Pull request description:
Change to always install libmultiprocess into `lib/`. On some systems (my Fedora aarch64 box), libmultiprocess was being installed into `lib64/`, and then configure would fail to pick it up, because we only add `lib/` to pkgconfig/ldflags out of depends. Rather than adding lib64 to those, I opted for installing libmultiprocess into lib, with every other dependency we build.
This was broken in our build after https://github.com/chaincodelabs/libmultiprocess/pull/79 upstream.
ACKs for top commit:
ryanofsky:
Code review ACK bde8d63b17637c507a543cebe90f2998b5847373. Only changes since last review were reverting the native_capnp change as suggested, and changing the order of the first two commits.
Tree-SHA512: ddd547e4ac224f2f199c569efd91104db7f2c243b124f9535aa0d9377315775ac566d699101580ce45ddd6676ad3e0c8cbe256334eeed9548205c2fa04d02102
11d797e3a078b8f5f0039a1073047d3f0a8c6cdc depends: Build `native_capnp` package with CMake (Hennadii Stepanov)
90389c95e9edf3d705fb9376388c83f07d1a570e depends: Build `capnp` package with CMake (Hennadii Stepanov)
Pull request description:
The first commit fixes two bugs when cross-compiling the `capnp` package on the master branch @ 160d23677ad799cf9b493eaa923b2ac080c3fb8e:
- for `x86_64-w64-mingw32` (see https://github.com/bitcoin/bitcoin/pull/28735#issuecomment-1790406668):
```
libtool: link: x86_64-w64-mingw32-g++-posix -shared -nostdlib /usr/lib/gcc/x86_64-w64-mingw32/12-posix/../../../../x86_64-w64-mingw32/lib/dllcrt2.o /usr/lib/gcc/x86_64-w64-mingw32/12-posix/crtbegin.o src/kj/.libs/cidr.o src/kj/.libs/common.o src/kj/.libs/units.o src/kj/.libs/memory.o src/kj/.libs/refcount.o src/kj/.libs/array.o src/kj/.libs/list.o src/kj/.libs/string.o src/kj/.libs/string-tree.o src/kj/.libs/source-location.o src/kj/.libs/hash.o src/kj/.libs/table.o src/kj/.libs/encoding.o src/kj/.libs/exception.o src/kj/.libs/debug.o src/kj/.libs/arena.o src/kj/.libs/io.o src/kj/.libs/mutex.o src/kj/.libs/thread.o src/kj/.libs/time.o src/kj/.libs/filesystem.o src/kj/.libs/filesystem-disk-unix.o src/kj/.libs/filesystem-disk-win32.o src/kj/.libs/test-helpers.o src/kj/.libs/main.o src/kj/parse/.libs/char.o -L/home/hebasto/git/bitcoin/depends/x86_64-w64-mingw32/lib -L/usr/lib/gcc/x86_64-w64-mingw32/12-posix -L/usr/lib/gcc/x86_64-w64-mingw32/12-posix/../../../../x86_64-w64-mingw32/lib -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 /usr/lib/gcc/x86_64-w64-mingw32/12-posix/crtend.o -mthreads -O2 -mthreads -mthreads -o .libs/libkj-1-0-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libkj.dll.a
/usr/bin/x86_64-w64-mingw32-ld: src/kj/.libs/cidr.o:cidr.c++:(.text+0x1dc): undefined reference to `__imp_inet_ntop'
/usr/bin/x86_64-w64-mingw32-ld: src/kj/.libs/cidr.o:cidr.c++:(.text+0x44b): undefined reference to `__imp_inet_pton'
collect2: error: ld returned 1 exit status
```
- for `arm64-apple-darwin`:
```
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `arm64-apple-darwin': machine `arm64-apple' not recognized
configure: error: /bin/bash build-aux/config.sub arm64-apple-darwin failed
```
The second commit applies the same changes for the `native_capnp` package for [consistency](https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1807936546).
ACKs for top commit:
ryanofsky:
Code review ACK 11d797e3a078b8f5f0039a1073047d3f0a8c6cdc. Since last review arm64-apple-darwin platform is now mentioned in the commit message, and the change to `depends/packages/libmultiprocess.mk` in d1604d4b1d1ee8df279a1776303e167cc3d06193 which was unrelated (but probably still a good optimization) was reverted.
Tree-SHA512: c636e53073ce6fcda9724723bc59f3990fa9629a3b2f73d93dbc102a5a1badfbe8f4c5fef841f03588ebcad5cd4883f3ce32b128afcd75f6bc21eb801796a586
a3a2bd9e8ad360a63cc8bdfc365d8bfd25ecc720 ci: Drop no longer needed package-specific flags (Hennadii Stepanov)
071eef1e974f128131afe6c6b5c68a430c64687a build: Propagate user-defined flags to host packages (Hennadii Stepanov)
Pull request description:
On master (4f8b1f8759301d2553183e14f72444a0f1d80725) `{CPP,C,CXX,LD}FLAGS` that are specified in the command line are not propagated to packages:
```
$ make --no-print-directory -C depends print-libevent_cxxflags CXXFLAGS=-some-fancy-flag
libevent_cxxflags=-pipe -O2
```
This PR:
- propagates `{CPP,C,CXX,LD}FLAGS` to host packages:
```
$ make --no-print-directory -C depends print-libevent_cxxflags CXXFLAGS=-some-fancy-flag
libevent_cxxflags= -some-fancy-flag
```
- does not propagate `{CPP,C,CXX,LD}FLAGS` to native packages:
```
$ make --no-print-directory -C depends print-native_b2_cxxflags CXXFLAGS=-some-fancy-flag
native_b2_cxxflags=
```
- actually addresses the https://github.com/bitcoin/bitcoin/pull/23551#issuecomment-973896518
ACKs for top commit:
TheCharlatan:
Code review ACK a3a2bd9e8ad360a63cc8bdfc365d8bfd25ecc720
Tree-SHA512: 243d6b1b0e9c5de46debc36de62a77b6b4d6f638940fd530040c219956ec624e321b0c25290fed164e3a8c88befa7b97b20f765d7b9a428c269b3720f21da099
556775408797d8e27154c3edaf139820b0979cce depends: build libevent with -D_GNU_SOURCE (fanquake)
Pull request description:
Currently, builds of libevent in depends, using CMake, fail on some systems, like Alpine, with the following:
```bash
/bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c: In function 'evmap_signal_add_':
/bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c:456:31: error: 'NSIG' undeclared (first use in this function)
456 | if (sig < 0 || sig >= NSIG)
```
From what I can tell the `GNU_SOURCE` "detection" in libevents CMake build system, never? really worked, primarily relies on looking for a deprecated define, and it's not clear what a nice fix is. For now, always build with `_GNU_SOURCE`, to match the autotools behaviour.
ACKs for top commit:
TheCharlatan:
ACK 556775408797d8e27154c3edaf139820b0979cce
Tree-SHA512: 4552b4a92867e8fa2af0ffa39b2be6c994bf739de7ce6a7c581590be486da81f7d93fca816854548c1e912347d33a35218c441b5058c3cbd3e82c74a9b7c78d9
d318c4ef56465ccad1a1d4d27c52216e0b69ad4e depends: bump libmultiprocess for CMake fixes (Cory Fields)
Pull request description:
Broken out of #30454 . Bumped [even further](4883197abc (r1684802528)) after https://github.com/chaincodelabs/libmultiprocess/pull/98 was merged upstream.
hebasto Presumably this approach works now with the CMake branch?
ACKs for top commit:
ryanofsky:
Code review ACK d318c4ef56465ccad1a1d4d27c52216e0b69ad4e.
Tree-SHA512: 4b5491f73c0063d09e8339829cd831b1f4c441dd7b55a22037c9337c80cce19bb00a3e5cf925efa77d6d4e89ab45482f40f5799bc14948f8cabcbad3c3549430
21bfee0720ba72935d4f9fc4c2a2887ae5b54092 depends: bump libmultiprocess to fix capnproto deprecation warnings (Ryan Ofsky)
Pull request description:
This incorporates PR chaincodelabs/libmultiprocess#88 and reverts the NO_WERROR CI workaround added in #28735
Upstream diff: 61d5a0e661...414542f81e
---
This PR is part of the [process separation project](https://github.com/bitcoin/bitcoin/issues/28722).
ACKs for top commit:
maflcko:
lgtm ACK 21bfee0720ba72935d4f9fc4c2a2887ae5b54092
hebasto:
ACK 21bfee0720ba72935d4f9fc4c2a2887ae5b54092, I have reviewed the code and it looks OK. I've also skimmed through the related changes in the https://github.com/chaincodelabs/libmultiprocess repository.
Tree-SHA512: b5addb0deed694eeec62a0ae08b4715a811110201f39f3e6cadee8fc4e6231b0e66c844a98512072a1445bac122ab561dc1711e27fb4d7ac5c08ac46780a4acf
BACKPORT NOTICE: excludes ci/test/00_setup_env_i686_multiprocess.sh changes, however, these do not satisfy enough this to be partial to me
3333f14efac815ba3c885398a6795c7e8ce68d08 depends: Bump to capnproto-c++-1.0.1 (MarcoFalke)
Pull request description:
Reasons:
* Debian is starting to ship this version in Trixie (https://packages.debian.org/trixie/capnproto), which will likely become the version shipped with Ubuntu 24.04 LTS. So testing with this version will help to find any issues before real users start to use those distro packages.
* The feature is currently experimental, so bumping the version shouldn't cause any production issues.
* With multiprocess begin a priority project for 27.0, it seems better to do build system changes/bumps early, rather than later, to allow for more time testing them.
ACKs for top commit:
TheCharlatan:
Re-ACK 3333f14efac815ba3c885398a6795c7e8ce68d08
fanquake:
ACK 3333f14efac815ba3c885398a6795c7e8ce68d08 - the response from upstream is that [if we submit a PR, they can take a look](https://github.com/capnproto/capnproto/issues/1833#issuecomment-1792582206), so if anyone would like this to work for Windows, I'd suggest sending a patch.
ryanofsky:
Code review ACK 3333f14efac815ba3c885398a6795c7e8ce68d08
Tree-SHA512: 7d53ad1536f042ab43dbc7847126b826e7fc76694f173c348b835fd1067b8f3dd682c5bcb4887f09ee85bab69130721cd7f8fb96b2e82053d4e28bd5c38bdc5f
007ea322a6492d46f1565ef58a0c49f5b468ff20 depends: switch to building libqrencode with CMake (fanquake)
884330c0a57ce839d48606dc2de3928869b31b7d guix: make cmake-minimal a global requirement (fanquake)
Pull request description:
Switch to building libqrencode with CMake. Note that upstream (https://github.com/fukuchi/libqrencode) hasn't seen any activity for ~4 years, so the odds of getting anything upstream seems low, but I've made two minor changes to the source here, which I will PR in any case.
From an initial look I couldn't find any significant difference between the Autotools and CMake produced libs. As part of this change we move cmake-minimal in Guix into the global package set.
ACKs for top commit:
TheCharlatan:
ACK 007ea322a6492d46f1565ef58a0c49f5b468ff20
Tree-SHA512: c784f790ddea958082c8ae96d3744bdf99331a8799765f9d44f00861b8e2cfcab1a88a3d64af5b10e51a8d5938d55eb6a3d271790b565e50492a39d00dc0e30f
63c0c4ff10b2f6ed8510ef372a5b1f6a6494b179 depends: reuse _config_opts for CMake options (Cory Fields)
Pull request description:
Context: I'm [currently experimenting with building our depends with CMake when possible](https://github.com/theuni/bitcoin/commits/depends-cmake) as part of our future transition to CMake. Specifically zmq, libevent, libnatpmp, and miniupnpc all have existing CMake buildsystems. Building them with CMake will allow us to drop several deps that we currently have (autoconf, automake, pkg-config, etc) which would be unfortunate to carry over after the switch-over.
But that's not relevant for this PR. This is just a very simple change that makes the above work easier to experiment with as it [adds a needed feature for CMake packages](5733dc2000 (diff-e6ed342a25092e0a6d0308e0bfd826044578847132cc6726ac4afa2ca767b61aR20)). It's a no-op for the current builds.
---
From commit description:
This will allow us to use the existing machinery for filtering by arch, os, debug/release, etc.
For example, the following becomes possible for libevent when building with CMake:
`$(package)_config_opts_release=-DEVENT__DISABLE_DEBUG_MODE`
Now the define is only set when not building depends with DEBUG=1
ACKs for top commit:
hebasto:
ACK 63c0c4ff10b2f6ed8510ef372a5b1f6a6494b179
Tree-SHA512: 17d123219d2f98c017880196966ffebd5d09d3e2db8e443e227eb7e49da46e9d971fbe7fd2b99a324fc367e1bbe0ac3cd15b399bce98dd87fbb144d767e15fe7
8c935e625ea75d180144f0526d6a0d5fd58c1f29 depends: Fix CMake-generated `libevent*.pc` files (Hennadii Stepanov)
Pull request description:
Broken out of #30454. This is a backport of the merged upstream PR: https://github.com/libevent/libevent/pull/1622.
Note that after #29835 we might end up dropping pkg-config and using the installed CMake files directly, but that depends on whether or not enough distros actually ship those files.
Either way, having fixed up .pc files won't hurt.
ACKs for top commit:
hebasto:
ACK 8c935e625ea75d180144f0526d6a0d5fd58c1f29.
fanquake:
ACK 8c935e625ea75d180144f0526d6a0d5fd58c1f29
Tree-SHA512: 259c2ad78fb9e90370a7205dc71c40acda1a872f6509435133bc1c4c2c3de57366e80679aa083e13ed85e7966883dc470c0147ee171a2ed0171a18cd5ffc99b3
f59e9057e2aa596b54cf9e85bab35c3ead137547 depends: switch libevent to CMake (Cory Fields)
Pull request description:
Switches libevent in depends to be built with CMake.
ACKs for top commit:
TheCharlatan:
ACK f59e9057e2aa596b54cf9e85bab35c3ead137547
willcl-ark:
ACK f59e9057e2aa596b54cf9e85bab35c3ead137547
Tree-SHA512: 875bf9bc57653c78775a1f8192a2c964fea8f4490d733ff796d9efb00e786f0ca9a7c1a3fd610cda032273c4f2ae06394585b03567d5f241ab073c83a47cf927
371910a7682ecdaf86b3e65753667746add1ecd2 depends: Fix CMake-generated `libzmq.pc` file (Hennadii Stepanov)
Pull request description:
This is a backport of: https://github.com/zeromq/libzmq/pull/4706.
Similar to https://github.com/bitcoin/bitcoin/pull/30488.
Addresses https://github.com/bitcoin/bitcoin/pull/29723#issuecomment-2239864170:
> Looking at the mingw .pc generated by this PR:
>
> ```
> Libs: -L${libdir} -lzmq
> Libs.private:
> Requires.private:
> ```
>
> It looks like we'll need to take [zeromq/libzmq#4706](https://github.com/zeromq/libzmq/pull/4706) as well for CMake. That can be done as a follow-up though, as it's not yet merged upstream.
ACKs for top commit:
fanquake:
ACK 371910a7682ecdaf86b3e65753667746add1ecd2
Tree-SHA512: 6f9c2e32f83c0e629e32fd3e4c86712af00ffeaf0906bf85e5c2df889302707b9df102e8031249d1bae036eb4fc019c2a5124655682fbc5652d9337cb21c5f2c
0388ad0d65b6c9ee802ca641eb01d69fcdd5605d depends: switch zmq to CMake (Cory Fields)
fefb3bbe5b538f8faa59de191914ad0c22c3ade6 depends: add zeromq no librt patch (fanquake)
a522ef15424110f76172b3c0603fa08f7291c9fc depends: add zeromq cmake minimum patch (fanquake)
cbbc229adf4c12ad4bd7edde71425b8ef217edfc depends: add zeromq windows usage patch (fanquake)
2de68d6d388b9a33c57234d3161f6ffc4c2a0246 depends: add zeromq builtin sha1 patch (fanquake)
0c8605253ae887dac316264cb969b752027d277a depends: add zeromq mktemp macos patch (fanquake)
Pull request description:
This picks up a change, which is a switch to building zeromq with CMake. It includes a number of patches, some which have already been upstreamed (see each patch for details).
ACKs for top commit:
hebasto:
ACK 0388ad0d65b6c9ee802ca641eb01d69fcdd5605d.
Tree-SHA512: 5567e432b4e4e0446c41d502bd61810a80b329dea2399b5d9d9f6e79acc450d1c6ba861c8238ba895de98338cfc5dc44ad2bf86ee8c222ecb3fbf47d6eb60da4
86c2889518df0234b8b28112a9771b85c577eefd ci: Make log verbose in error case only (Hennadii Stepanov)
7f650883b71b67cd33026cf49af0b16f01e45541 depends: Add file-based logging for individual packages (Hennadii Stepanov)
Pull request description:
This PR adds file-based logging for individual packages in depends. To use this feature one should provide `LOG=1`.
A log file is printed out automatically in case of a build error. After successful build log files are being moved along with package archives:
```
$ make -C depends HOST=x86_64-w64-mingw32 LOG=1
$ find ./depends/built/x86_64-w64-mingw32 -name '*.log' | sort
./depends/built/x86_64-w64-mingw32/bdb/bdb-4.8.30-5100a099801.log
./depends/built/x86_64-w64-mingw32/boost/boost-1_71_0-313f82dc7de.log
./depends/built/x86_64-w64-mingw32/libevent/libevent-2.1.12-stable-3fa27048d5e.log
./depends/built/x86_64-w64-mingw32/libnatpmp/libnatpmp-4536032ae32268a45c073a4d5e91bbab4534773a-9db4850dd32.log
./depends/built/x86_64-w64-mingw32/miniupnpc/miniupnpc-2.2.2-75d9a1807e0.log
./depends/built/x86_64-w64-mingw32/native_b2/native_b2-1_71_0-3bf253c19bf.log
./depends/built/x86_64-w64-mingw32/qrencode/qrencode-3.4.4-dfac87af599.log
./depends/built/x86_64-w64-mingw32/qt/qt-5.15.2-9304e03d3ac.log
./depends/built/x86_64-w64-mingw32/sqlite/sqlite-3320100-455acafa7be.log
./depends/built/x86_64-w64-mingw32/zeromq/zeromq-4.3.1-5ff627ec84a.log
```
An example of CI tasks with package build errors -- https://cirrus-ci.com/task/5275741788045312Closes#16368.
ACKs for top commit:
laanwj:
Tested ACK 86c2889518df0234b8b28112a9771b85c577eefd
Tree-SHA512: 497f2146fd2e38c952124aecfd80ebb42be22bbc5dc59521491545f4465fc38f23da7787a0caea5686b7c30aa862f2b0c02092ae3fe863e80a5ddd14b3d324b9
BACKPORT NOTE: excludes documentation changes in doc/build-android.md
4ba492052ec09d48f8c3f391cc248340e761c7f2 doc: Add minimum supported Android NDK version (Hennadii Stepanov)
6393bdcd53b106367b10317c227a114494c90142 doc: Move Android dependencies guide into `build-android.md` (Hennadii Stepanov)
ac323a7222efaafc7bc3110b02f1ef2d2635c9a2 build: Switch to llvm buinutils for Android builds (Hennadii Stepanov)
Pull request description:
The new Long Term Support release of the Android NDK is [available](https://groups.google.com/g/android-ndk-announce/c/MS6Qoub0DKE/m/Zfp5Ys8eAAAJ) since 2021-08-11:
> As r23 is the new LTS, the support windows for r21 and r22 have now ended.
On master (8ae4ba481ce8f7da173bef24432729c87a36cb70), dependency build fails because it expects GNU Binutils are present in the Android NDK. In [fact](https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#binutils):
> GNU Binutils remains available up to and including r22. All binutils tools with the exception of the assembler (GAS) were removed in r23. GAS was removed in r24.
This PR switches our depends build system to llvm binutils. The usage of `llvm-ar` and `llvm-ranlib` tools effectively makes r21 the minimum supported version of NDK.
With this PR:
- building depends against NDK r23 LTS now is possible with `NO_QT=1`
- building the `qt` package in depends against NDK r23 LTS still fails:
```
Creating qmake...
...
ERROR: Cannot detect Android NDK toolchain.
Please use -android-toolchain-version to specify it.
```
The issue with the `qt` package is going to be addressed in another PR.
ACKs for top commit:
fanquake:
ACK 4ba492052ec09d48f8c3f391cc248340e761c7f2
Tree-SHA512: cdc8f95ff9a3ad7f12eb55b9ea18b6b6b800d4cceff7e0321985be6e39d15a2b2ea5b1592972307d76d111292a0ed58fd287e5ca285e2f6868b42a286536d310
986d7fed057b995a720787cbbd21e1c41763fb83 depends: zeromq 4.3.5 (fanquake)
Pull request description:
First new point release of zeromq in two and a half years. Mostly bug fixes; the project also completed a relicense to the "Mozilla Public License".
See https://github.com/zeromq/libzmq/releases/tag/v4.3.5.
ACKs for top commit:
hebasto:
ACK 986d7fed057b995a720787cbbd21e1c41763fb83, I have reviewed the code and it looks OK.
TheCharlatan:
ACK 986d7fed057b995a720787cbbd21e1c41763fb83
Tree-SHA512: cdd6abfbbe10873c1ca267fed648c2e6ff17a4aff50c414924006e63fa39d501e803f8893a5cd966a2078b5c077f2578e482483e6723ea6f5760f16211d40998
1914e470e327091c625f627b4447beb336f7fe5a build: copy config.{guess,sub} post autogen in zmq package (fanquake)
Pull request description:
Otherwise our config.guess and config.sub will be copied over. This problem has been masked by the fact that modern systems ship with versions that recognise all the triplets we use (namely arm64-apple-darwin). However building on ubuntu 20.04 surfaces the issue.
Fixes#26420.
ACKs for top commit:
hebasto:
ACK 1914e470e327091c625f627b4447beb336f7fe5a, tested on Ubuntu 18.04.
Tree-SHA512: dff64c3c62d9f8fc205e5a4dffe8befd58838418d073a15dfe304a0f64b182dfffd9dcf98b53df44bfab905c12a62d03cd5c0f91fa7c4b246ac21ae5f20540fd
e037c4fe0914d8fa9149ce7532c0d70f738e79e9 depends: always configure with --with-pic (fanquake)
Pull request description:
We currently do this sporadically. Not only amongst packages, but across OS's, i.e sometimes it's done for BSDs/Android, and sometimes not.
Configure with `--with-pic` globally instead. I think this generally makes more sense, and should not have any downsides.
See related discussion in https://github.com/bitcoin/bitcoin/pull/28846#discussion_r1399123100.
ACKs for top commit:
hebasto:
ACK e037c4fe0914d8fa9149ce7532c0d70f738e79e9.
Tree-SHA512: efc743ff92f9f99f3ac16514e98363ad395c6f956cd4be7e785b5c573685baf7fcd68c51d6a705ee8761fc676eb045b7e61676595be0eb0f70f34e99174cddc0
5fb8f0f80fc41cc636da56864195244d8fd9116e depends: Do not override CFLAGS when building SQLite with DEBUG=1 (Hennadii Stepanov)
2b0dd88f1ce9084324dc54db578fade9c926fd71 depends: Ensure definitions are passed when building SQLite with DEBUG=1 (Hennadii Stepanov)
Pull request description:
The `--enable-debug` configure option for the SQLite package does two things:
```autoconf
#-----------------------------------------------------------------------
# --enable-debug
#
AC_ARG_ENABLE(debug, [AS_HELP_STRING(
[--enable-debug], [build with debugging features enabled [default=no]])],
[], [])
AC_MSG_CHECKING([Build type])
if test x"$enable_debug" = "xyes"; then
BUILD_CFLAGS="$BUILD_CFLAGS -DSQLITE_DEBUG -DSQLITE_ENABLE_SELECTTRACE -DSQLITE_ENABLE_WHERETRACE"
CFLAGS="-g -O0"
AC_MSG_RESULT([debug])
else
AC_MSG_RESULT([release])
fi
#-----------------------------------------------------------------------
```
It adds three preprocessor definitions and overrides `CFLAGS` with `"-g -O0"`. The latter breaks the user's ability to provide sanitizer and LTO flags.
This PR might be especially useful for OSS-Fuzz where `DEBUG=1` has been used since https://github.com/google/oss-fuzz/pull/10503.
Also it makes a workaround for building SQLite for 32-bit unneeded. For details, please refer to https://github.com/hebasto/oss-fuzz/tree/240120-sqlite.
Changes in https://github.com/bitcoin/bitcoin/pull/29282 might not be strictly required now. However, I consider them an improvement.
ACKs for top commit:
fanquake:
ACK 5fb8f0f80fc41cc636da56864195244d8fd9116e - downstream is also green, so i'll fixup the PR there.
Tree-SHA512: 8593d8a0237ebb270d5da763fb65ed642ab8ed0d44e57704a34154621f49e3d5c58b462cc0070251fa1ba556c58a3c7d3620530d6839dc6dc9e0887010330eca
56a03f1834a7437e3357923a1e45e512c9b2e6fc depends: ensure we are appending to sqlite cflags (fanquake)
Pull request description:
Otherwise we'll just override other flags passed in (i.e msan).
Should fix https://cirrus-ci.com/task/6598922274078720?logs=ci#L3661.
ACKs for top commit:
achow101:
ACK 56a03f1834a7437e3357923a1e45e512c9b2e6fc
TheCharlatan:
ACK 56a03f1834a7437e3357923a1e45e512c9b2e6fc
Tree-SHA512: 5890018cfc5deaef18b0f01a3a0396f803e97f9a9785bf6873ef48bc13b74b644315f0f29cf11d3522964a6396f74e1f080bb4e412bc302956a651fed28b27df
dee690257c7948510a0661e23c9e398a13e20659 build: pass --enable-debug to sqlite when DEBUG=1 (fanquake)
807b61fcca6d301286ae43d00f88d986a985ea38 build: use more recommended sqlite3 compile options (fanquake)
Pull request description:
https://www.sqlite.org/compile.html
[SQLITE_DQS](https://www.sqlite.org/compile.html#dqs)
> This setting disables the double-quoted string literal misfeature.
[SQLITE_DEFAULT_MEMSTATUS](https://www.sqlite.org/compile.html#default_memstatus)
> This setting causes the sqlite3_status() interfaces that track
> memory usage to be disabled.
> This helps the sqlite3_malloc() routines run much faster, and since
> SQLite uses sqlite3_malloc() internally, this helps to make the
> entire library faster.
[SQLITE_OMIT_DEPRECATED](https://www.sqlite.org/compile.html#omit_deprecated)
> Omitting deprecated interfaces and features will not help SQLite
> to run any faster.
> It will reduce the library footprint, however. And it is the
> right thing to do.
[SQLITE_OMIT_SHARED_CACHE](https://www.sqlite.org/compile.html#omit_shared_cache)
> Omitting the possibility of using shared cache allows many
> conditionals in performance-critical sections of the code to be
> eliminated. This can give a noticeable improvement in performance.
Also: https://www.sqlite.org/sharedcache.html
> Shared-cache mode is an obsolete feature.
> The use of shared-cache mode is discouraged.
> Most use cases for shared-cache are better served by WAL mode.
> Applications that build their own copy of SQLite from source code
> are encouraged to use the -DSQLITE_OMIT_SHARED_CACHE compile-time
> option, as the resulting binary will be both smaller and faster.
[SQLITE_OMIT_JSON](https://www.sqlite.org/compile.html#omit_json)
> Starting with sqlite 3.38.0 the JSON extension became opt-out rather
than opt-in, so we disable it here.
--disable-rtree
> An R-Tree is a special index that is designed for doing range queries.
> R-Trees are most commonly used in geospatial systems...
https://www.sqlite.org/rtree.html
--disable-fts4 --disable-fts5
> FTS5 is an SQLite virtual table module that provides full-text
> search functionality to database applications.
DSQLITE_LIKE_DOESNT_MATCH_BLOBS
> simplifies the implementation of the LIKE optimization and allows
> queries that use the LIKE optimization to run faster.
DSQLITE_OMIT_DECLTYPE
> By omitting the (seldom-needed) ability to return the declared type of
> columns from the result set of query, prepared statements can be made
> to consume less memory.
DSQLITE_OMIT_PROGRESS_CALLBACK
> By omitting this interface, a single conditional is removed from the
> inner loop of the bytecode engine, helping SQL statements to run slightly
> faster.
DSQLITE_OMIT_AUTOINIT
> with the SQLITE_OMIT_AUTOINIT option, the automatic initialization is omitted.
> This helps many API calls to run a little faster
> it also means that the application must call sqlite3_initialize()
manually.
On my Linux box this results in a `libsqlite3.a` that shrinks from ~1.7mb to ~1.3mb.
On macOS, `libsqlite3.a` shrinks from ~2.2mb to ~1.3mb.
Guix Build:
```bash
04626ec7b64086103bfb5537397d7953d0699b31da1b1bc100003c7d30991fdf guix-build-dee690257c79/output/aarch64-linux-gnu/SHA256SUMS.part
a77c72052266788e890a0d3d89cc6eee9dd72db6a1b6fdc8aab882b35a315284 guix-build-dee690257c79/output/aarch64-linux-gnu/bitcoin-dee690257c79-aarch64-linux-gnu-debug.tar.gz
86d782f185ee0fae8e8733ab8a511de2ca2500f02eb3d4aaa20d65b4434dcd77 guix-build-dee690257c79/output/aarch64-linux-gnu/bitcoin-dee690257c79-aarch64-linux-gnu.tar.gz
d81874ecd378470b01a429f2a4be07fcb4824b56ace146226b77088cc3c41baa guix-build-dee690257c79/output/arm-linux-gnueabihf/SHA256SUMS.part
8f24076800e5a19ac9005af8c6e4987b32e0a857a83af84931958505228ef58d guix-build-dee690257c79/output/arm-linux-gnueabihf/bitcoin-dee690257c79-arm-linux-gnueabihf-debug.tar.gz
b913f2b0d8f0e32a176bc0e9330106cf1973afe6e8ee955f3eeb89918ab9d565 guix-build-dee690257c79/output/arm-linux-gnueabihf/bitcoin-dee690257c79-arm-linux-gnueabihf.tar.gz
034b47d8a60a19391e0e18f6fcc8fb3a87be78a9707e3ac3e7ee45eb37687bb7 guix-build-dee690257c79/output/arm64-apple-darwin/SHA256SUMS.part
9efc5c0ceac05f6efce03fcde0cbe8b79bae43fe0d98aecb817908e76f5c39b7 guix-build-dee690257c79/output/arm64-apple-darwin/bitcoin-dee690257c79-arm64-apple-darwin-unsigned.dmg
a549cdcbd311d9b025971b13987290f6cd2b93e16c8389e8a7a2ccd3608326ed guix-build-dee690257c79/output/arm64-apple-darwin/bitcoin-dee690257c79-arm64-apple-darwin-unsigned.tar.gz
3dd9e26a41596151022aa4288d778dc335a2b38bd391e3f65c0575dd6eb47b54 guix-build-dee690257c79/output/arm64-apple-darwin/bitcoin-dee690257c79-arm64-apple-darwin.tar.gz
a71685a3ff62fbf456fc1d3c0f78ab7ab1d5a4a094c1f43d3829730d65a3ec51 guix-build-dee690257c79/output/dist-archive/bitcoin-dee690257c79.tar.gz
d5c74167b2260b7de72fdbac77eedacbbb929214e279e07f41c3236ea20116b6 guix-build-dee690257c79/output/powerpc64-linux-gnu/SHA256SUMS.part
03c043daa971f70886805c9e4174acd600e5cda03ae0e827043c4df81a6a6426 guix-build-dee690257c79/output/powerpc64-linux-gnu/bitcoin-dee690257c79-powerpc64-linux-gnu-debug.tar.gz
3884423f67d48f671a90169962f9568dcbd8df582cd269df29a4399dc9c70e99 guix-build-dee690257c79/output/powerpc64-linux-gnu/bitcoin-dee690257c79-powerpc64-linux-gnu.tar.gz
cee2847d4feeadebfdf4d37110faafa250824c68cfefc3bfa289ae8b09599a20 guix-build-dee690257c79/output/powerpc64le-linux-gnu/SHA256SUMS.part
ca9f1085184b50e7bd377b68a58afd42ac4055ffe214eede8c6ca7291e00b45a guix-build-dee690257c79/output/powerpc64le-linux-gnu/bitcoin-dee690257c79-powerpc64le-linux-gnu-debug.tar.gz
b9cadff5b30244f6cb4f277e1ac610841332cb0d732637fe438fd51c88adf5a4 guix-build-dee690257c79/output/powerpc64le-linux-gnu/bitcoin-dee690257c79-powerpc64le-linux-gnu.tar.gz
db6e45d9fc8868e5cb25fa3d0789247db10a6bab2a6f3866a27d641ae00bd03b guix-build-dee690257c79/output/riscv64-linux-gnu/SHA256SUMS.part
751e90c0aefa249f175c0c1707dc5eee3637e2b9657a9ee1b2068479e9830ff0 guix-build-dee690257c79/output/riscv64-linux-gnu/bitcoin-dee690257c79-riscv64-linux-gnu-debug.tar.gz
8dd87bb24f1fbdba67fb6b72ab5fc93532452eada8c2942463100b8ed8118ae3 guix-build-dee690257c79/output/riscv64-linux-gnu/bitcoin-dee690257c79-riscv64-linux-gnu.tar.gz
b53fe650f431e394a5af6bd809401551e3c36e4f7d90c31f39f51c5fe236efaf guix-build-dee690257c79/output/x86_64-apple-darwin/SHA256SUMS.part
b35b4ae345a625e42b8315acd9b75bb651f60265f67ec6f7d78a41c8d21c635e guix-build-dee690257c79/output/x86_64-apple-darwin/bitcoin-dee690257c79-x86_64-apple-darwin-unsigned.dmg
6748e4c64ae069632624cbec20de7f03eca1a7578fcef96607f3e8cb0ac4106e guix-build-dee690257c79/output/x86_64-apple-darwin/bitcoin-dee690257c79-x86_64-apple-darwin-unsigned.tar.gz
6415cbecfa18002a1e4865b996268558b4f26121118fd73b0ef4ca44967f34c7 guix-build-dee690257c79/output/x86_64-apple-darwin/bitcoin-dee690257c79-x86_64-apple-darwin.tar.gz
f0a8d8837e80e42b5d77c3efc9d746c11ffc9909aece16dcba0a10726e1be7e0 guix-build-dee690257c79/output/x86_64-linux-gnu/SHA256SUMS.part
418f4607159387ee17657120beda1c741fa6060e4457b304b857aa6c33859e6a guix-build-dee690257c79/output/x86_64-linux-gnu/bitcoin-dee690257c79-x86_64-linux-gnu-debug.tar.gz
d384fe8f2d6515c256a371ad84ae76ac9727ffd49887c0e22bb5ada4cd890092 guix-build-dee690257c79/output/x86_64-linux-gnu/bitcoin-dee690257c79-x86_64-linux-gnu.tar.gz
3f441eb2d68ddd530b32f56a16ff639b27dcc58b5ba395e40f4c2be805f6cd8b guix-build-dee690257c79/output/x86_64-w64-mingw32/SHA256SUMS.part
d3d22479adc554ced965c4bde79f4c919e6b216acfca598fac4ebfc3b0e2d39d guix-build-dee690257c79/output/x86_64-w64-mingw32/bitcoin-dee690257c79-win64-debug.zip
89de153f5d839df6cd1266f8b3cb3ad455b2f6c43cee7644889da1e3efc7b2f1 guix-build-dee690257c79/output/x86_64-w64-mingw32/bitcoin-dee690257c79-win64-setup-unsigned.exe
ba30708b9551b3794e4d2726aff27775dd4f1b347ea71b3fe1b00e39e8b7a594 guix-build-dee690257c79/output/x86_64-w64-mingw32/bitcoin-dee690257c79-win64-unsigned.tar.gz
ab6a2b7a3e899fc58030a44b555e449d64aa69b5215d761bc550946b14f93515 guix-build-dee690257c79/output/x86_64-w64-mingw32/bitcoin-dee690257c79-win64.zip
```
ACKs for top commit:
Sjors:
tACK dee690257c7948510a0661e23c9e398a13e20659
achow101:
ACK dee690257c7948510a0661e23c9e398a13e20659
hebasto:
ACK dee690257c7948510a0661e23c9e398a13e20659, I have reviewed the code and it looks OK.
Tree-SHA512: e0605f049404905db94ea61473b2b68df008ceb86b9a09d8562ca3acc1f3a3be3893149fc62d189a6fbf24cfc76c393f2d1a1215292e9ae5dc4afc199e876821
eb1c3adf38cb71c3e6f298a61871738c4919b4a1 depends: qrencode 4.1.1 (fanquake)
Pull request description:
Upgrade to the latest qrencode, and disable some warnings that cause compile failures with newer compilers (clang-15+).
I haven't tested this (from a GUI perspective) at all. This is just "good enough" to keep things compiling, and uses some similar work-arounds as we have with other older packages, i.e bdb.
Note that upstream, libqrencode is effectively unmaintained. No code changes for > 2 years. No responses to issues/PRs. Seems like the author has mostly dropped off of GitHub as well.
This fixes part of #27299.
ACKs for top commit:
TheCharlatan:
Code review ACK eb1c3adf38cb71c3e6f298a61871738c4919b4a1
Tree-SHA512: 898eaac3e9915dfcdc0a011b736fff685a3b46990bd27f6038ef4d3e7cb6a276206438ea50d45908a051ce55c9b0779347d4be1d35271b67f76f409a7dc21fed
f8b8458276983f8fc1e2a47c4d00c1e30633067d depends: fix compiling bdb with clang-16 on aarch64 (fanquake)
Pull request description:
Compiling bdb with clang-16 on aarch64 (hardware) currently fails:
```bash
make -C depends/ bdb CC=clang CXX=clang++
...
checking for mutexes... UNIX/fcntl
configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM.
configure: error: Unable to find a mutex implementation
```
Looking at config.log we've got:
```bash
configure:18704: checking for mutexes
configure:18815: clang -o conftest -pipe -std=c11 -O2 -Wno-error=implicit-function-declaration -Wno-error=format-security -I/bitcoin/depends/aarch64-unknown-linux-gnu/include -D_GNU_SOURCE -D_REENTRANT -L/bitcoin/depends/aarch64-unknown-linux-gnu/lib conftest.c -lpthread >&5
conftest.c:45:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
main() {
^
int
conftest.c:50:2: warning: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
exit (
^
conftest.c:50:2: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
1 warning and 1 error generated.
```
Clang-16 changed `-Wimplicit-function-declaration` and `-Wimplicit-int`
warnings into errors, see:
https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes.
> The -Wimplicit-function-declaration and -Wimplicit-int warnings now
> default to an error in C99, C11, and C17. As of C2x, support for implicit
> function declarations and implicit int has been removed, and the
> warning options will have no effect. Specifying -Wimplicit-int in
> C89 mode will now issue warnings instead of being a noop.
ACKs for top commit:
hebasto:
ACK f8b8458276983f8fc1e2a47c4d00c1e30633067d, tested on Ubuntu Lunar (`aarch64`) with:
Tree-SHA512: 5ca078b1c00915446e9f0f2ecaa4342295a2097996554345753315d1c81c23000c57be14e1ac5506a87820f5114aba748456f2c2b6426b0810504d62d761a787
0e02f725482dd30b9f03903074a481af1164411d depends: define `__BSD_VISIBLE` for FreeBSD bdb build (fanquake)
Pull request description:
Required for additional definitions (`IPC_R` & friends), to be available, when compiling under C11, which would otherwise cause compile fails.
See: https://github.com/MarcoFalke/btc_nightly/pull/4.
ACKs for top commit:
hebasto:
ACK 0e02f725482dd30b9f03903074a481af1164411d, tested on FreeBSD 13.1:
Tree-SHA512: 885d4aa341d9668da360cf6dfafb97ce816803c54e76c0a06e448db39a723666d42cd14b3e713d17ecbe33163f5af69924567cf449d679a2db95b36357005d43
Reasonably enough I guess, it appears that a number of our dependencies block github runner IP addresses? the blobs stored at the s3 link were downloadable from the normal location when accessed locally, but returned a 404 from github runners. These blobs were also not present in the bitcoincore depends-sources anyhow.
f4cb0fbfe1 fix: no need to relay quorum commitment in case of block undo (Konstantin Akimov)
0431a33919 fix: follow-up changes for bitcoin#14193. (Konstantin Akimov)
86b76d19b6 Merge bitcoin/bitcoin#21812: ci: Enable D_GLIBCXX_DEBUG for multiprocess task (fanquake)
334496ea7e Merge bitcoin/bitcoin#21775: p2p: Limit m_block_inv_mutex (MarcoFalke)
23b83109ea Merge bitcoin/bitcoin#21750: net: remove unnecessary check of CNode::cs_vSend (MarcoFalke)
b34514191f Merge bitcoin/bitcoin#21738: test: Use clang-12 for ASAN, Add missing suppression (fanquake)
3411577473 Merge bitcoin/bitcoin#19160: multiprocess: Add basic spawn and IPC support (W. J. van der Laan)
970048d917 fix: missing changes from bitcoin#19267 - run multiprocess on CI (Konstantin Akimov)
f2b7ee73db fix: follow-up bitcoin#15402 - removed dead code (Konstantin Akimov)
274068cdbc fix: follow-up bitcoin/bitcoin#21732 - minor missing typo (MarcoFalke)
e9450a8b36 Merge #21669: test: Remove spurious double lock tsan suppressions by bumping to clang-12 (MarcoFalke)
ef92c3065c Merge #21663: ci: Fix macOS brew install command (W. J. van der Laan)
Pull request description:
## Issue being fixed or feature implemented
Just regular backports from v22
## What was done?
See commits for backports.
Also there're 2 bugs are fixed which became visible after backporting bitcoin#21775 - both are related to possible deadlocks in net_processing
## How Has This Been Tested?
Run unit and functional tests. Enabled multiprocess builds on CI
## Breaking Changes
N/A
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
ACKs for top commit:
UdjinM6:
utACK f4cb0fbfe1
PastaPastaPasta:
utACK f4cb0fbfe1
Tree-SHA512: 3204c2aa243fa4834ccf4ff4672d183cf9b35f87b857df8543572cd685729e15fca39f85b27194233e57cbc1746e36b556efab95ce20d0aa0a7d4476a9f3c6c0
84934bf70e11fe4cda1cfda60113a54895d4fdd5 multiprocess: Add echoipc RPC method and test (Russell Yanofsky)
7d76cf667eff512043a28d4407cc89f58796c42b multiprocess: Add comments and documentation (Russell Yanofsky)
ddf7ecc8dfc64cf121099fb047e1ac871de94f4c multiprocess: Add bitcoin-node process spawning support (Russell Yanofsky)
10afdf0280fa93bfffb0a7665c60dc155cd84514 multiprocess: Add Ipc interface implementation (Russell Yanofsky)
745c9cebd50fea1664efef571dc1ee1bddc96102 multiprocess: Add Ipc and Init interface definitions (Russell Yanofsky)
5d62d7f6cd48bbc4e9f37ecc369f38d5e1e0036c Update libmultiprocess library (Russell Yanofsky)
Pull request description:
This PR is part of the [process separation project](https://github.com/bitcoin/bitcoin/projects/10).
---
This PR adds basic process spawning and IPC method call support to `bitcoin-node` executables built with `--enable-multiprocess`[*].
These changes are used in https://github.com/bitcoin/bitcoin/pull/10102 to let node, gui, and wallet functionality run in different processes, and extended in https://github.com/bitcoin/bitcoin/pull/19460 and https://github.com/bitcoin/bitcoin/pull/19461 after that to allow gui and wallet processes to be started and stopped independently and connect to the node over a socket.
These changes can also be used to implement new functionality outside the `bitcoin-node` process like external indexes or pluggable transports (https://github.com/bitcoin/bitcoin/pull/18988). The `Ipc::spawnProcess` and `Ipc::serveProcess` methods added here are entry points for spawning a child process and serving a parent process, and being able to make bidirectional, multithreaded method calls between the processes. A simple example of this is implemented in commit "Add echoipc RPC method and test."
Changes in this PR aside from the echo test were originally part of #10102, but have been split and moved here for easier review, and so they can be used for other applications like external plugins.
Additional notes about this PR can be found at https://bitcoincore.reviews/19160
[*] Note: the `--enable-multiprocess` feature is still experimental, and not enabled by default, and not yet supported on windows. More information can be found in [doc/multiprocess.md](https://github.com/bitcoin/bitcoin/blob/master/doc/multiprocess.md)
ACKs for top commit:
fjahr:
re-ACK 84934bf70e11fe4cda1cfda60113a54895d4fdd5
ariard:
ACK 84934bf. Changes since last ACK fixes the silent merge conflict about `EnsureAnyNodeContext()`. Rebuilt and checked again debug command `echoipc`.
Tree-SHA512: 52a948b5e18a26d7d7a09b83003eaae9b1ed2981978c36c959fe9a55abf70ae6a627c4ff913a3428be17400a3dace30c58b5057fa75c319662c3be98f19810c6
BACKPORT NOTICE:
missing changes in src/test/validation_tests.cpp (signet)
1112035d32ffe73a4522226c8cb2f6a5878d3ada doc: fix various typos (Ikko Ashimine)
e8640849c775efcf202dbd34736fed8d61379c49 doc: Use https URLs where possible (Sawyer Billings)
Pull request description:
Consolidates / fixes the changes from #20762, #20836, #20810. There is no output when `test/lint/lint-all.sh` is run.
Closes#20807.
ACKs for top commit:
MarcoFalke:
ACK 1112035d32ffe73a4522226c8cb2f6a5878d3ada
Tree-SHA512: 22ca824688758281a74e5ebc6a84a358142351434e34c88c6b36045d2d241ab95fd0958565fd2060f98317e62e683323b5320cc7ec13592bf340e6922294ed78
148b33cf72033eced8a701d127e21dfe8a816ce3 build: Replace `which` command with `command -v` (Hennadii Stepanov)
Pull request description:
On some systems the `which` command can emit messages into stderr. For example, for `debianutils 5.5-1` package in Debian Sid:
```
# which cat
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
/bin/cat
```
Although such messages are harmless, they could distract developers needlessly (see bitcoin/bitcoin#24056).
Fixesbitcoin/bitcoin#24056.
ACKs for top commit:
dongcarl:
Code Review ACK 148b33cf72033eced8a701d127e21dfe8a816ce3
laanwj:
Code review ACK 148b33cf72033eced8a701d127e21dfe8a816ce3
Tree-SHA512: 36ee45d8831afb75a1ba6f8c8491fa5381159a2b86042140ac09037752f74e92d3e725caa793b8e97c36afe03ada0b557eede95df2bec049173c27f32ffc804a
8f1ff487b3df6f3e4cb53f88045a32ea4fbc0839 libxcb: use a patch instead of sed (fanquake)
Pull request description:
To remove the unneeded pthread-stubs requirement.
Should almost be enough to close#16838.
seds dead (mostly). The usage left in `qt.mk` are for substituting runtime values.
ACKs for top commit:
hebasto:
ACK 8f1ff487b3df6f3e4cb53f88045a32ea4fbc0839.
Tree-SHA512: 2b6ebbe98a838d8e08e54737292b02176ff4c85a541ae1ec0c590c75e33ba92289628b88ca3144f2e214f4327515f7fd22c39687312f44183b759815c092b24f
Old version doesn't support debug information for ELF produced by modern compilers
It appears like an error:
> unrecognized DWARF version in .debug_info at 6
> no debug info in ELF executable
which causes:
> No debug information available for stacktrace. You should add debug information and then run
And backtraces are not shown on linux even if debug infos here.
With this fixes output as expected:
```
std::terminate() called due to unhandled exception
Exception: type=char const*, what="HEHE"
0#: (0x5D7C19364C3F) bitcoind.cpp:114 - AppInit
1#: (0x5D7C19364C3F) bitcoind.cpp:273 - main
2#: (0x7B0B19C28150) libc_start_call_main.h:74 - __libc_start_call_main
3#: (0x7B0B19C28209) libc-start.c:128 - call_init
4#: (0x7B0B19C28209) libc-start.c:347 - __libc_start_main_impl
5#: (0x5D7C193734D5) <unknown-file> - ???
```
8047bb6feaa9ee5d6c1edb7640baaf228450bc6b build: Update `qt` package up to 5.15.11 (Hennadii Stepanov)
Pull request description:
In the light of https://github.com/bitcoin/bitcoin/pull/28622, we probably have to patch Qt. It seems reasonable to update it up to the latest available version before doing that.
ACKs for top commit:
TheCharlatan:
ACK 8047bb6feaa9ee5d6c1edb7640baaf228450bc6b
Tree-SHA512: b4d7df2ff059b8f58c3202d913237c0d39a962748658f1ce853884dca095fbda5f56d4d68f73a1bc8da2f295e96a20927306e148b41a9f4afc42c8edb11c3729
f7f3829a68df173c54ab11ecfe162b840afb64e8 build, doc: Drop libbz2-dev from macOS cross-compiling dependencies (Hennadii Stepanov)
d8239362e283107657a5a6577890fdb198a1d334 build, doc: Drop libcap-dev from macOS cross-compiling dependencies (Hennadii Stepanov)
Pull request description:
The `libcap-dev` and `libbz2-dev` packages are no longer required when cross-compiling for macOS.
ACKs for top commit:
fanquake:
ACK f7f3829a68df173c54ab11ecfe162b840afb64e8
Tree-SHA512: 820cdc2724f3346c0942d4d4115fc7206f7bf02889d9fa6cbdbd1d9e3afa03a067c1c3fa64dff596aefdc74898178b7c7d64027a6501486e3b606f4760de04ae
173ef8980d921c9c0e46257747ab1165965e3ced build: Small libxcb.mk improvements (Hennadii Stepanov)
5129b36573cb07d8bcbac493506c46e26d7239eb build: Clean remnants of QTBUG-34748 fix (Hennadii Stepanov)
Pull request description:
Hope, this PR will make [transit](https://github.com/bitcoin/bitcoin/pull/21376) to Qt 5.12.10 neater.
A fix for [QTBUG-34748](https://bugreports.qt.io/browse/QTBUG-34748) was introduced in #5915 (v0.11.0, Qt 5.2.1).
[QTBUG-34748](https://bugreports.qt.io/browse/QTBUG-34748) was [fixed](b19b080894) in Qt 5.3.0.
The separated [`fix-xcb-include-order.patch`](bb44d9e754/depends/patches/qt/fix-xcb-include-order.patch), provided by #5915, was dropped in #12971 while bumping Qt to 5.9.4 (5.9.6). But `libxcb.mk` remained unchanged.
This PR reverts #5915 for `libxcb.mk` as well.
ACKs for top commit:
practicalswift:
cr ACK 173ef8980d921c9c0e46257747ab1165965e3ced: patch looks correct
fanquake:
ACK 173ef8980d921c9c0e46257747ab1165965e3ced
Tree-SHA512: 9815a7e532ff4aa08f9623ded8d5708eca1c9c73ac7a2684419a18c125da7627b44ac3191f2e7978946942c8d0580e73b1a93df624986fb2a13791a68ce1e025
8b8edc25c13a3e613770bf38b21a2556192e6315 build: Specify native binaries explicitly when building `capnp` package (Hennadii Stepanov)
a413595c37f51557f9506e0a279cd80fc9a6fb36 build: Fix `capnp` package build for Android (Hennadii Stepanov)
Pull request description:
On master (e3c08eb620a2f317fc09fdf20969fa26f02afb91):
```
$ make -C depends capnp MULTIPROCESS=1 HOST=aarch64-linux-android ANDROID_SDK=$ANDROID_HOME ANDROID_NDK=$ANDROID_HOME/ndk/23.2.8568313 ANDROID_API_LEVEL=28 ANDROID_TOOLCHAIN_BIN=$ANDROID_HOME/ndk/23.2.8568313/toolchains/llvm/prebuilt/linux-x86_64/bin
...
ld: error: unable to find library -lkj
...
```
This PR fixes this error, and also improves configuring according to the docs.
ACKs for top commit:
ryanofsky:
Code review ACK 8b8edc25c13a3e613770bf38b21a2556192e6315. I'd be a little curious to know what causes the error and how `--disable-shared` fixes it, but these changes all look good
Tree-SHA512: 1b07b75f2a83932d8dc1f007e42a67d8327bd5fe4566f554dab4599e2a1e04b0144648790a1fd2ab1c295dba728586035aa0ebdbe5cf49df048ec87736895aaf
e838a9847580527b8321d65e57b1c53cc2af6bf4 depends: re-enable using -flto when building expat (fanquake)
304452558c7f6f5e32ba13d8f05325790c8a4f5f depends: expat 2.4.8 (fanquake)
Pull request description:
Currently, when building the expat package in depends, using `-flto` (`LTO=1`), the configure check can fail, because it cannot determine the system endianess:
```bash
configure:18718: result: unknown
configure:18733: error: unknown endianness
presetting ac_cv_c_bigendian=no (or yes) will help
```
Fix that by defining `_DEFAULT_SOURCE`, which in turn defines `__USE_MISC` (`features.h`):
```c
#if defined _DEFAULT_SOURCE
# define __USE_MISC1
#endif
```
which exposes additional definitions in `endian.h`:
```c
#include <features.h>
/* Get the definitions of __*_ENDIAN, __BYTE_ORDER, and __FLOAT_WORD_ORDER. */
#include <bits/endian.h>
#ifdef __USE_MISC
# define LITTLE_ENDIAN__LITTLE_ENDIAN
# define BIG_ENDIAN__BIG_ENDIAN
# define PDP_ENDIAN__PDP_ENDIAN
# define BYTE_ORDER__BYTE_ORDER
#endif
```
and gives us a working configure.
You could test building this change with Guix + LTO with [this branch](https://github.com/fanquake/bitcoin/tree/lto_in_guix). Note that that build may fail for other reasons (on x86_64), unrelated to this change.
Some related upstream discussion:
https://bugs.gentoo.org/757681https://forums.gentoo.org/viewtopic-t-1013786.html
ACKs for top commit:
hebasto:
re-ACK e838a9847580527b8321d65e57b1c53cc2af6bf4, only [suggested](https://github.com/bitcoin/bitcoin/pull/25697#discussion_r929735675) changes since my recent [review](https://github.com/bitcoin/bitcoin/pull/25697#pullrequestreview-1050657421).
jarolrod:
code review ACK e838a9847580527b8321d65e57b1c53cc2af6bf4
Tree-SHA512: 9dbf64c9bd1fd995a4d1addc011ffeff83d50df736030012346c97605e63aed4b5bac390a81abe646c1be28ad6fd600f64560dcb26bbc2edf5d513ca3b180bfa
c0f5cc14ef9fae2b2de4222ee061729629ebb6b4 build: Fix `libmultiprocess` cross-compiling to Linux hosts (Hennadii Stepanov)
Pull request description:
To successfully call the [`capnp_generate_cpp()`](d576d975de/CMakeLists.txt (L45)) function, the `libmultiprocess` build system must be provided with paths to the native `capnp` and `capnpc-c++` tools.
This [comment](https://github.com/bitcoin/bitcoin/issues/24387#issuecomment-1054776195) points the same:
> I think `packages/libmultiprocess.mk` probably needs to be passing a `-DCAPNP_EXECUTABLE=.../depends/arm-linux-gnueabihf/native/bin/capnp` argument to cmake. Also the package should have dependencies on both `capnp` and `native_capnp`.
Fixesbitcoin/bitcoin#24387.
ACKs for top commit:
ryanofsky:
Code review ACK c0f5cc14ef9fae2b2de4222ee061729629ebb6b4
Tree-SHA512: 2986d8bf98d2761eceba21b1897145c5185a0922d4c2084e8812d4d07dc94237e5c2809036641c4f7c491a3414727fff328cba91ce138b89e37ec5cba61d8f61
7c218dacd0e9602b8f755be42e96c49706f96305 build: specify cmake build dir for multiprocess depends build (fanquake)
Pull request description:
When no build dir is specified, cmake will warn:
```bash
Preprocessing libmultiprocess...
Configuring libmultiprocess...
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
```
It's unclear if this will actually ever become an error, but it's also easy
enough to just supply the directory, and save this maybe breaking in
future.
ACKs for top commit:
ryanofsky:
Code review ACK 7c218dacd0e9602b8f755be42e96c49706f96305. I guess the purpose of the warning is to encourage people not to build in the source directory, but reasons for encouraging this don't really apply to the depends build system, so it is appropriate to disable the warning.
hebasto:
ACK 7c218dacd0e9602b8f755be42e96c49706f96305, tested on Ubuntu 22.04.
Tree-SHA512: 6904f2095fe62cead4abc644ec888c5d836e54a3c0b2a84c467029116e5d14eba35190570acaa23c6831aed9a4a65898134480cc46cdb141279ec0dc6f534d5f
07dcf1a76e34a6f7c919e7d5c57fa61caea6007b build: remove boost dep from libmultiprocess (fanquake)
Pull request description:
Looks like this hasn't been needed since https://github.com/chaincodelabs/libmultiprocess/pull/25 and was just missed in #19160.
ACKs for top commit:
ryanofsky:
Code review ACK 07dcf1a76e34a6f7c919e7d5c57fa61caea6007b. Should probably wait for GUIX build results, but I think this should be fine
hebasto:
ACK 07dcf1a76e34a6f7c919e7d5c57fa61caea6007b
Tree-SHA512: 7988efd4aaf6ad512d60cfd33f350df56090daf88aac3aed2a1d400e80bc723dc27d27f5fa5d75359f9fae60d04b87d4b120d4e79e3079df8631956ab6c3b83c
ff4a38a32766942ce5c4be6d6510f800a9f8e0d9 build: Fix configuring depends with cmake (Hennadii Stepanov)
Pull request description:
This PR fixesbitcoin/bitcoin#24389.
On master (28aa0e3ca0a6cfeb5b2b63929d4bc58de6ee6f02) configuring of the `libmultiprocess` package for the `x86_64-w64-mingw32` target fails:
```
$ cd depends
$ make libmultiprocess_configured MULTIPROCESS=1 HOST=x86_64-w64-mingw32
Configuring libmultiprocess...
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
-- The CXX compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++-posix
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++-posix -- broken
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCXXCompiler.cmake:53 (message):
The C++ compiler
"/usr/bin/x86_64-w64-mingw32-g++-posix"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_93273/fast && make[1]: Entering directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_93273.dir/build.make CMakeFiles/cmTC_93273.dir/build
make[2]: Entering directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o
/usr/bin/x86_64-w64-mingw32-g++-posix -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 -o CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o -c /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
Linking CXX executable cmTC_93273
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_93273.dir/link.txt --verbose=1
/usr/bin/x86_64-w64-mingw32-g++-posix -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 -L/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/lib -rdynamic CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o -o cmTC_93273
x86_64-w64-mingw32-g++-posix: error: unrecognized command line option ‘-rdynamic’
make[2]: *** [CMakeFiles/cmTC_93273.dir/build.make:87: cmTC_93273] Error 1
make[2]: Leaving directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
make[1]: *** [Makefile:121: cmTC_93273/fast] Error 2
make[1]: Leaving directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:6 (project)
-- Configuring incomplete, errors occurred!
See also "/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeOutput.log".
See also "/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeError.log".
make: *** [funcs.mk:283: /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/./.stamp_configured] Error 1
```
The reason of that failure is the unset `-DCMAKE_SYSTEM_NAME` flag:
```
$ make print-libmultiprocess_cmake MULTIPROCESS=1 HOST=x86_64-w64-mingw32
libmultiprocess_cmake=env CC="x86_64-w64-mingw32-gcc" CFLAGS=" -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 " CXX="x86_64-w64-mingw32-g++-posix" CXXFLAGS=" -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 " LDFLAGS=" -L/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/lib " cmake -DCMAKE_INSTALL_PREFIX:PATH="/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32" -DCMAKE_SYSTEM_NAME= -DCMAKE_C_COMPILER_TARGET=x86_64-w64-mingw32 -DCMAKE_CXX_COMPILER_TARGET=x86_64-w64-mingw32
```
This PR fixes this error:
```
$ make libmultiprocess_configured MULTIPROCESS=1 HOST=x86_64-w64-mingw32
$ # no errors
```
ACKs for top commit:
fanquake:
ACK ff4a38a32766942ce5c4be6d6510f800a9f8e0d9 - going to merge this now, and we can follow up with more cmake improvements.
Tree-SHA512: bd8d8b2f4eedcc8c46cf995b9c39493ea4d0b13c224f77ef62985304ebd392f05119043a06f1401c64f962007a8faa4bb53715d99a408ee6c33bb49a2dd650ba
01e121d29087db047e4bc01bd64d054f83cfc5df depends: fix capnp's descriptor for make download (Cory Fields)
Pull request description:
The non-native capnp was trying to fetch the wrong file.
Without this, "make -C depends MULTIPROCESS=1 download" is broken.
Presumably it breaks with the download target because the dependency graph is flattened. It manages to work if native_capnp is encountered first because it will then be found in the cache.
ACKs for top commit:
gruve-p:
tACK 01e121d290
hebasto:
ACK 01e121d29087db047e4bc01bd64d054f83cfc5df, tested on Linux Mint 20.2 (x86_64).
Tree-SHA512: 2605d895f3799be5a311f6f7d36a5c13cdb715dc148915ad818f4afc7d5de92cd6b8ecd34ff2b21cef6743b090819bba1e3353096cfb5659c55f76113ce5adf3
735610940c0cac72343ca247eb3062b2e09512a0 build: set --build when configuring packages in depends (fanquake)
Pull request description:
After reading [#Specifying-Target-Triplets](https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/autoconf.html#Specifying-Target-Triplets) in the autoconf manuel, my understanding is that this change should mostly be a no-op, as `--build` defaults to the output of [`config.guess`](https://github.com/bitcoin/bitcoin/blob/master/depends/config.guess), however, this may be slightly more correct
> For historical reasons, whenever you specify --host, be sure to specify --build too; this will be fixed in the future.
and will quell some warnings in depends (#16354), i.e:
> configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
If anything, this also explicitly enables cross-compilation mode when `--host` differs from `--build`. As for "fixed in the future", this is the case for Autoconf 2.70+.
If we don't make this change, I think we should consider closing #16354. We've now got a good handle on our depends configure flags, and we can just leave the last few warnings as they are. It's also unlikely that we are going to add the `xorg-macros` package to depends.
Guix builds at 735610940c0cac72343ca247eb3062b2e09512a0:
```bash
bash-5.1# find output -type f -name *$(git rev-parse --short HEAD)*.* -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
afabf99650d57abd3df2c7e6253a3281f9814ada77d01c28ffb57c740b14fd8e output/bitcoin-735610940c0c-aarch64-linux-gnu-debug.tar.gz
6e9dedced61489f7734c5387ee05823db68eb4b890fa05f11541c1b966576446 output/bitcoin-735610940c0c-aarch64-linux-gnu.tar.gz
5333a3c5978a61966251e56fedab8e059d9d8a1a7231a0908095bb373204a81f output/bitcoin-735610940c0c-arm-linux-gnueabihf-debug.tar.gz
d28e1c166b96e58cf40b3f9801c3050c2785b25eeb261d44eeb31a32a75e134c output/bitcoin-735610940c0c-arm-linux-gnueabihf.tar.gz
e00b0149c52e9207be1cfb56ec3b715b55f41691401095f7a7038ac124f08d80 output/bitcoin-735610940c0c-osx-unsigned.dmg
ae5052ad1a05916bc6656b034c169097471fd9bdba16b606e2bcb592c9395544 output/bitcoin-735610940c0c-osx-unsigned.tar.gz
8586a9b8b82a8832397fcd0756aa9649adc3e61ae579fb370b99fe406298199f output/bitcoin-735610940c0c-osx64.tar.gz
d560a8781bae856b6593e9b731fa99de0a4ad7bd3e03084166dc98904ece9e7b output/bitcoin-735610940c0c-powerpc64-linux-gnu-debug.tar.gz
a24cf28b7efd5ebdc892e7e8809a05b3405bb4222f7d2eaa32de265214c78f28 output/bitcoin-735610940c0c-powerpc64-linux-gnu.tar.gz
ad29421842dbbe96526eb597a7ff2970f0acae8c3e75dc6c2100716a2ba20606 output/bitcoin-735610940c0c-powerpc64le-linux-gnu-debug.tar.gz
ee7a8ccfd68cc2297bb96eaaacf7b3eb939a5e39cecc3c710dbe828518f1bfbd output/bitcoin-735610940c0c-powerpc64le-linux-gnu.tar.gz
185bf4ea3b35072a8dd54aedbafc0892ec1e486c8ebd311f05f0fb47a19058cf output/bitcoin-735610940c0c-riscv64-linux-gnu-debug.tar.gz
803078b15a9bbaa567176827639895e762edbe80844b80400f8a9581e5311d32 output/bitcoin-735610940c0c-riscv64-linux-gnu.tar.gz
d920327a32a42a5abadd247f0d3f3ee0ab0488a28892c11838d99bede6456723 output/bitcoin-735610940c0c-win-unsigned.tar.gz
9f1741a37e294af153d57ad4a6dad3e5f1cdf75f1588c86cb467abf0c177ae27 output/bitcoin-735610940c0c-win64-debug.zip
2d1a91552c0dd7bb400ce6c71d2e98de702743a97afe5f4b0945865f251f3aea output/bitcoin-735610940c0c-win64-setup-unsigned.exe
8a70020bb0cb68516acf4b2cc89832d72373f31611bd075826a30a817a071cd2 output/bitcoin-735610940c0c-win64.zip
93b03837679474905538e96c44ba81ee5653795ad333dc00569b92c82dc6ea31 output/bitcoin-735610940c0c-x86_64-linux-gnu-debug.tar.gz
6ccd046a83ef5089667ad426875319beb83e2b2a5fb4d4459d5c5ce8d75f1a31 output/bitcoin-735610940c0c-x86_64-linux-gnu.tar.gz
12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc output/src/bitcoin-735610940c0c.tar.gz
```
Gitian builds:
```bash
# macOS:
7d087749f610e5e3eca91c730d41afd4d404808e276242d05cedb89403de247f bitcoin-735610940c0c-osx-unsigned.dmg
96d68b4f0042dc40f5e8e362fa84dcf8e122dcb566889feb48ad8a982847dd8b bitcoin-735610940c0c-osx-unsigned.tar.gz
2dea72cbe5c3e228babd88b516a6f43b0e040e9510ea95b62f07fc0815bf8d22 bitcoin-735610940c0c-osx64.tar.gz
12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc src/bitcoin-735610940c0c.tar.gz
478dbda9d551a8bed985c61c625df3f543afab26989a52bc44d5a4745715af81 bitcoin-core-osx-22-res.yml
# Windows:
c31a5118dfa21259b9868e2c4858c635becb786c2ee8af92302da7811a1efe9b bitcoin-735610940c0c-win-unsigned.tar.gz
5c171ec3aee830abc8ae843d674d5fe7a57420e782ee765b6992914ae5b7671a bitcoin-735610940c0c-win64-debug.zip
ca010ced982f75d111e01f3759b961deb83e7bf511b1ee9c9041f4830570f2a0 bitcoin-735610940c0c-win64-setup-unsigned.exe
62514b01281f81af6057fb12cc5e3813c1d8f6532d0d8ac8f6f2909a595aa1dd bitcoin-735610940c0c-win64.zip
12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc src/bitcoin-735610940c0c.tar.gz
e26b55d8302a419f594396db6ff441aaeb5e275e02fde7b1b4eb092270f902e7 bitcoin-core-win-22-res.yml
# Linux:
e5be4deb91cb372de484468c0575a04f907f982e35a9841659bb213540f770d0 bitcoin-735610940c0c-aarch64-linux-gnu-debug.tar.gz
6169e822679ece2bb6af7027362a6f373eb939eef9d89edc58c21190b4083c7d bitcoin-735610940c0c-aarch64-linux-gnu.tar.gz
aee5308767c5c930853a80ab94325b2a4ab3dbe9a7a20c7a9d60d57af2b5383f bitcoin-735610940c0c-arm-linux-gnueabihf-debug.tar.gz
a9cf6e56d859fffd5a2b5f1e6360515bc6b06b048776b93cc08954859457a251 bitcoin-735610940c0c-arm-linux-gnueabihf.tar.gz
7617d85c358e6614fd40026a8d346f9edba5b5139e3daade2ec2aec72aed3a1f bitcoin-735610940c0c-powerpc64-linux-gnu-debug.tar.gz
f76e46a8b130812541ebcaaba173b4cbe2ec1781e348579b44f96e9244cc2475 bitcoin-735610940c0c-powerpc64-linux-gnu.tar.gz
19ada7abb801422bd7772d7ee559004cab11a46141a747aabd27085e8c3d200d bitcoin-735610940c0c-powerpc64le-linux-gnu-debug.tar.gz
f3a6bbefe9f47b3960e3b9eeb3f740ecddf8773ae76961ced6a3cdf82503e37f bitcoin-735610940c0c-powerpc64le-linux-gnu.tar.gz
42ca333e8f82b4ec0b2354efc7c4f1c27ed32d60c35b88e33d26833419f19e69 bitcoin-735610940c0c-riscv64-linux-gnu-debug.tar.gz
dde930d9134fb5be1374014db3f6f503b614ae801a1d77f6f4b82a5f11eb2518 bitcoin-735610940c0c-riscv64-linux-gnu.tar.gz
82e1b4cc8aac309a99458cc27fd0285215a8af53780094c4990303ce8948cf0c bitcoin-735610940c0c-x86_64-linux-gnu-debug.tar.gz
ee8caad2ccddd8eaf8aa2d19040d859130168183355b09a2a0f77a59a97fcaee bitcoin-735610940c0c-x86_64-linux-gnu.tar.gz
12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc src/bitcoin-735610940c0c.tar.gz
d90545b13226a338c994d9e538f468a6fafd694273bf71e14614feeaf5727ad4 bitcoin-core-linux-22-res.yml
```
ACKs for top commit:
dongcarl:
Code Review ACK 735610940c0cac72343ca247eb3062b2e09512a0
hebasto:
ACK 735610940c0cac72343ca247eb3062b2e09512a0, tested on Linux Mint 20.1 (x86_64).
Tree-SHA512: 13ce05269309a12d03b81a539ba5585003785f7b1bb7894a9353385a6e9c709f920cc4f79322f28d7a256809754f201e70be6b917915c7b14e1461530075781d
7d0271b5c30f86e4af175a5ab7df5e593cd85195 depends: Set CMAKE_INSTALL_RPATH for native packages (Russell Yanofsky)
Pull request description:
This PR is part of the [process separation project](https://github.com/bitcoin/bitcoin/projects/10).
---
After #19685 started setting `LDFLAGS`, the `INSTALL_RPATH_USE_LINK_PATH` cmake option used in the libmultiprocess build no longer works, so it is neccessary to set `CMAKE_INSTALL_RPATH` as a fallback.
It's unclear currently whether the bad interaction between `INSTALL_RPATH_USE_LINK_PATH` and `LDFLAGS` is a bug, but the issue is reported:
- https://github.com/bitcoin/bitcoin/issues/19981#issuecomment-696680877
- https://discourse.cmake.org/t/install-rpath-use-link-path-not-working-when-cmake-exe-linker-flags-ldflags-is-set/1892Fixes#19981
ACKs for top commit:
fanquake:
ACK 7d0271b5c30f86e4af175a5ab7df5e593cd85195 - I haven't looked in depth, but I've re-read through #19981 and checked the failure by testing #19160 (with this reverted):
dongcarl:
ACK 7d0271b Looked into this a bit, it makes sense that for the things we build in depends, we want the library search to start in depends. It seems reasonable to expect this to happen automatically when `CMAKE_INSTALL_PREFIX` and `INSTALL_RPATH_USE_LINK_PATH` are set, but oh well...
Tree-SHA512: 97cc5801c3204c14cd33004423631456ca0701e2127ee5146810a76e2f4aac9de1f4b5437402a4329cda54e022dc99270fee7e38c2995765f36b3848215fa78e
b8936883573708059357a66f67fad9dc77a8bade depends: Specify LDFLAGS to cmake as well (Carl Dong)
b3f541f618fe1f3d44baf6a0dd4299173c81f752 depends: Prepend CPPFLAGS to C{,XX}FLAGS for CMake (Carl Dong)
8e121e550953711cd03d7b6c221afd065c325c5e depends: Cleanup CMake invocation (Carl Dong)
8c7cd0c6d9f295bcb6913e3c69c9dac4ce2b25ce depends: More robust cmake invocation (Carl Dong)
3ecf0eca634601da216b06f091f95456c047f39c depends: Use $($(package)_cmake) instead of cmake (Carl Dong)
Pull request description:
- Use `$($(package)_cmake)` instead of invoking `cmake` directly
- Use well-known env vars instead of overriding CMake variables
ACKs for top commit:
ryanofsky:
Code review ACK b8936883573708059357a66f67fad9dc77a8bade. Only changes since last review are new commits adding whitespace, cppflags and ldflags to cmake invocation
Tree-SHA512: cfcd8cc9dcd0b336cf48b82fca9fe4bbc7930ed397cb7a68a07066680eb4c1906a6a9b5bd2589b4b4999e8f16232fa30ee9b376b60f4456d0fff931fbf9cc19a
e2bab2aa162ae38b2bf8195b577c982402fbee9d multiprocess: add multiprocess travis configuration (Russell Yanofsky)
603fd6a2e708c04ef6c9880f89d0a4cbaa6fc7c5 depends: add MULTIPROCESS depends option (Russell Yanofsky)
5d1377b52bfcd4edf8553aaf332bfeb92fc554cc build: multiprocess autotools changes (Russell Yanofsky)
Pull request description:
This PR is part of the [process separation project](https://github.com/bitcoin/bitcoin/projects/10).
---
This PR consists of build changes only. It adds an `--enable-multiprocess` autoconf option (off by default and marked experimental), that builds new `bitcoin-node` and `bitcoin-gui` binaries. These currently function the same as existing `bitcoind` and `bitcoin-qt` binaries, but are extended in #10102 with IPC features to execute node, wallet, and gui functions in separate processes.
In addition to adding the `--enable-multiprocess` config flag, it also adds a depends package and autoconf rules to build with the [libmultiprocess](https://github.com/chaincodelabs/libmultiprocess) library, and it adds new travis configuration to exercise the build code and run functional tests with the new binaries.
The changes in this PR were originally part of #10102 but were moved into #16367 to be able to develop and review the multiprocess build changes independently of the code changes. #16367 was briefly merged and then reverted in #18588. Only change since #16367 has been dropping the `native_boost.mk` depends package which was pointed out to be no longer necessary in https://github.com/bitcoin/bitcoin/pull/16367#issuecomment-596484337 and https://github.com/bitcoin/bitcoin/pull/18588#pullrequestreview-391765649
ACKs for top commit:
practicalswift:
ACK e2bab2aa162ae38b2bf8195b577c982402fbee9d
Sjors:
tACK e2bab2aa162ae38b2bf8195b577c982402fbee9d on macOS 10.15.4
hebasto:
ACK e2bab2aa162ae38b2bf8195b577c982402fbee9d, tested on Linux Mint 19.3 (x86_64):
Tree-SHA512: b5a76eab5abf63d9d8b6d628cbdff4cc1888eef15cafa0a5d56369e2f9d02595fed623f4b74b2cf2830c42c05a774f0943e700f9c768a82d9d348cad199e135c
060a2a64d40d75fecb60b7d2b9946a67e46aa6fc ci: remove boost thread installation (fanquake)
06e1d7d81d5a56d136c6fc88f09a2b0654a164f9 build: don't build or use Boost Thread (fanquake)
7097add83c8596f81be9edd66971ffd2486357eb refactor: replace Boost shared_mutex with std shared_mutex in sigcache (fanquake)
8e55981ef834490c438436719f95cbaf888c4914 refactor: replace Boost shared_mutex with std shared_mutex in cuckoocache tests (fanquake)
Pull request description:
This replaces `boost::shared_mutex` and `boost::unique_lock` with [`std::shared_mutex`](https://en.cppreference.com/w/cpp/thread/shared_mutex) & [`std::unique_lock`](https://en.cppreference.com/w/cpp/thread/unique_lock).
Even though [some concerns were raised](https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696) in #16684 with regard to `std::shared_mutex` being unsafe to use across some glibc versions, I still think this change is an improvement. As I mentioned in #21022, I also think trying to restrict standard library feature usage based on bugs in glibc is not only hard to do, but it's not currently clear exactly how we do that in practice (does it also extend to patching out use in our dependencies, should we be implementing more runtime checks for features we are using, when do we consider an affected glibc "old enough" not to worry about? etc). If you take a look through the [glibc bug tracker](https://sourceware.org/bugzilla/describecomponents.cgi?product=glibc) you'll no doubt find plenty of (active) bug reports for standard library code we already using. Obviously not to say we shouldn't try and avoid buggy code where possible.
Two other points:
[Cory mentioned in #21022](https://github.com/bitcoin/bitcoin/pull/21022#issuecomment-769274179):
> It also seems reasonable to me to worry that boost hits the same underlying glibc bug, and we've just not happened to trigger the right conditions yet.
Moving away from Boost to the standard library also removes the potential for differences related to Boosts configuration. Boost has multiple versions of `shared_mutex`, and what you end up using, and what it's backed by depends on:
* The version of Boost.
* The platform you're building for.
* Which version of `BOOST_THREAD_VERSION` is defined: (2,3,4 or 5) default=2. (see [here](https://www.boost.org/doc/libs/1_70_0/doc/html/thread/build.html#thread.build.configuration) for some of the differences).
* Is `BOOST_THREAD_V2_SHARED_MUTEX` defined? (not by default). If so, you might get the ["less performant, but more robust"](https://github.com/boostorg/thread/issues/230#issuecomment-475937761) version of `shared_mutex`.
A lot of these factors are eliminated by our use of depends, but users will have varying configurations. It's also not inconceivable to think that a distro, or some package manager might start defining something like `BOOST_THREAD_VERSION=3`. Boost tried to change the default from 2 to 3 at one point.
With this change, we no longer use Boost Thread, so this PR also removes it from depends, the build system, CI etc.
Previous similar PRs were #19183 & #20922. The authors are included in the commits here.
Also related to #21022 - pthread sanity checking.
ACKs for top commit:
laanwj:
Code review ACK 060a2a64d40d75fecb60b7d2b9946a67e46aa6fc
vasild:
ACK 060a2a64d40d75fecb60b7d2b9946a67e46aa6fc
Tree-SHA512: 572d14d8c9de20bc434511f20d3f431836393ff915b2fe9de5a47a02dca76805ad5c3fc4cceecb4cd43f3ba939a0508178c4e60e62abdbaaa6b3e8db20b75b03
f13e642c831c5689cb2bb7f5c4f9cb4c0c03ef21 build: Disable valgrind when building zeromq package in depends (Hennadii Stepanov)
b970f03beae0f3ae6a796f0e3b97732fc579f6aa build: Disable libbsd when building zeromq package in depends (Hennadii Stepanov)
77899991b1e29a45bc377b21330148cb7cc08923 build: Update netbsd_kevent_void.patch (Hennadii Stepanov)
Pull request description:
Since v4.3.3 (068385c951) `libzmq` uses `libbsd` by default.
This PR disables `libbsd` explicitly, as it's not a part of our depends. Zeromq will fallback to its internal `strlcpy` implementation.
Otherwise, on systems with installed `libbsd-dev` package the `zeromq` package build system erroneously detects `libbsd` package from the host system:
```diff
--- a/libzmq.pc
+++ b/libzmq.pc
@@ -8,5 +8,5 @@
Version: 4.3.4
Libs: -L${libdir} -lzmq
Libs.private: -lpthread
-Requires.private:
+Requires.private: libbsd
Cflags: -I${includedir}
```
This causes the `configure` fails to detect the `zeromq` package:
```
configure: WARNING: libzmq version 4.x or greater not found, disabling
```
---
Other minor improvements:
- fixed `netbsd_kevent_void.patch` offset
- disabled valgrind as it's used in unit tests which we do not run:
```diff
--- a/zmq-configure-output
+++ b/zmq-configure-output
@@ -119,11 +119,6 @@
checking whether the g++ -m64 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
-checking for valgrind... valgrind
-checking for Valgrind tool memcheck... memcheck
-checking for Valgrind tool helgrind... helgrind
-checking for Valgrind tool drd... drd
-checking for Valgrind tool exp-sgcheck... exp-sgcheck
checking linker version script flag... --version-script
checking if version scripts can use complex wildcards... yes
checking for working posix_memalign... yes
```
ACKs for top commit:
fanquake:
ACK f13e642c831c5689cb2bb7f5c4f9cb4c0c03ef21
Tree-SHA512: d4c86d4a841eb6e7c32157e84972243072f905496c2a4c14ec6f6ab4216df6695cbf29baa2233ce27eaede35d1e250ad2f9975b16f570d01509f0c5da4597cad
6897c4bdf51a4aa74320ebfffa9467db14670109 build: patch depends zeromq to fix building on NetBSD Current (fanquake)
ce6dd2f1a2e2c56d86d00e0eeec34c9982017416 zeromq 4.3.4 (fanquake)
Pull request description:
This is a prerequisite for #23955. It updates zeromq to the latest available version, and adds a patch, [that I've sent upstream](https://github.com/zeromq/libzmq/pull/4326), to fix building on NetBSD Current (10).
ACKs for top commit:
hebasto:
ACK 6897c4bdf51a4aa74320ebfffa9467db14670109, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: d05d9753630faebe842e1ca70c8c4af660a38e7331a9d95e84df3a3b14564c5118ca41c4fc49fb71dfee563b63e1014e5a3f8874d652e26de59e8e188a12970e
## Issue being fixed or feature implemented
Fix linter error:
```
In depends/config.site.in line 66:
if test "x@host_os@" = xdarwin; then
^----------^ SC2268 (style): Avoid x-prefix in comparisons as it no longer serves a purpose.
Did you mean:
if test "@host_os@" = darwin; then
For more information:
https://www.shellcheck.net/wiki/SC2268 -- Avoid x-prefix in comparisons as ...
^---- failure generated from test/lint/lint-shell.sh
```
## How Has This Been Tested?
run linter `test/lint/lint-all.sh`
## Breaking Changes
N/A
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
continued from a2687d4594 from dash#4379
includes:
- 4af59a407a207e7de327c1bb145d68ebc8ddedd8
inapplicable:
- 335bd7f8bc415d6419763e17b013f94e5f0e5689
above commit is inapplicable as boost 1.71 bump did away with the patch,
backported as 6a367fc198 in dash#4356
we're currently using boost 1.77, this replacement was dropped in its
patch form in bitcoin#19764 (backported as 6a367fc1 in dash#4356), the
comment was dropped in bitcoin#19761 but the change is in this commit
instead due to direct relevance.
e644591426fb4ee1bba5c4bfdde85eb378258272 build, refactor: Drop useless `call` Make function (Hennadii Stepanov)
Pull request description:
Using the [`call`](https://www.gnu.org/software/make/manual/html_node/Call-Function.html) function with `$(package)_*_cmds` is effectively noop because the latter, which could be found in `<package>.mk` files, do not use temporary `$(1)` variable at all.
This PR removes useless calls of the `call` function, and makes code more readable and easier to reason about.
No change in resulted dependency binaries could be easy verified with bitcoin/bitcoin/#21995.
ACKs for top commit:
laanwj:
Code review ACK e644591426fb4ee1bba5c4bfdde85eb378258272
shaavan:
Code review ACK e644591426fb4ee1bba5c4bfdde85eb378258272
Tree-SHA512: 8481fa0dc5bbf7dd6a180f7fae5a2ccc07f85b50c7a966bceb2d7e010e07e5f211ee3f74f8ac79bc5acfde5f0764264d599d959ff3ebb8511b1b4a33f79509bd
28f17c1a6de7b50482d8f55fe03698126862e8eb build: fix copypasta in OpenBSD C{XX} flags (fanquake)
Pull request description:
Introduced in #23998.
ACKs for top commit:
hebasto:
ACK 28f17c1a6de7b50482d8f55fe03698126862e8eb, I have reviewed the code and it looks OK, not tested on OpenBSD though.
Tree-SHA512: d905161534075f518c8924d3c42cca7ff8d4898e559f1daa9bd03dac95b109b2c3e76790fb8bc65b9e45e8a59566825afbf4dc3734ad74617dfdf797430e486b
