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
339b4a51f6d3558c3489b14efe0c8c195295cf86 build: don't install deprecated libevent headers (fanquake)
Pull request description:
We don't use the deprecated headers now, and never should do in the
future, so there is no need for them to exist in depends.
The headers themselves are just full of includes for the newer headers.
ACKs for top commit:
hebasto:
ACK 339b4a51f6d3558c3489b14efe0c8c195295cf86
Tree-SHA512: 736fd9e3b22212da462cc05203dd253806dc59f973090357b705f2742ed4a3b8c3cc44b3173d706527f60ad93e95cf4143ec6b7db4233a489890a98f8e5c8f07
bcd36e14f0a2b89445f1436094de40696d6ad76c build: correct depends FreeBSD C{XX}FLAGS (fanquake)
7b06ffce9c50110b475c722918c55a14402346a5 build: add NetBSD support to depends (fanquake)
Pull request description:
Similar to #23948. Doesn't build the Qt package; I haven't looked at doing that yet, but have an assumption that it's going to fail out of the box similar to the FreeBSD build.
Guix Build:
```bash
```
ACKs for top commit:
theuni:
ACK bcd36e14f0a2b89445f1436094de40696d6ad76c
Tree-SHA512: 9a0946cefbcb9a92dd730b885463f3213e304c8d4b39fea8d831fc013a73d2ef998ca84e384bf45a01fa1449cf5a35eaffaa5b57a9062c2cdda34312d33ec3fc
