depends: Bump to capnproto-c++-1.0.1 #28735

maflcko · 2023-10-26T11:45:20Z

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.

DrahtBot · 2023-10-26T11:45:23Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	TheCharlatan, fanquake, ryanofsky

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

maflcko · 2023-10-26T12:08:02Z

https://cirrus-ci.com/task/6337577544843264?logs=ci#L1948

  CXX      bitcoin_node-bitcoind.o
  CXX      init/bitcoin_node-bitcoin-node.o
  GEN      ipc/capnp/echo.capnp.h
  GEN      ipc/capnp/init.capnp.h
  CXX      ipc/capnp/libbitcoin_ipc_a-echo.capnp.o
  CXX      ipc/capnp/libbitcoin_ipc_a-init.capnp.o
  CXX      ipc/capnp/libbitcoin_ipc_a-echo.capnp.proxy-client.o
  CXX      ipc/capnp/libbitcoin_ipc_a-init.capnp.proxy-client.o
  CXX      ipc/capnp/libbitcoin_ipc_a-echo.capnp.proxy-server.o
  CXX      ipc/capnp/libbitcoin_ipc_a-init.capnp.proxy-server.o
  CXX      ipc/capnp/libbitcoin_ipc_a-echo.capnp.proxy-types.o
  CC       src/libsecp256k1_precomputed_la-precomputed_ecmult.lo
  CXX      ipc/capnp/libbitcoin_ipc_a-init.capnp.proxy-types.o
In file included from ipc/capnp/echo.capnp.proxy-server.c++:4:
/ci_container_base/depends/i686-pc-linux-gnu/include/mp/proxy-types.h:122:13: error: 'mvCapture<(lambda at /ci_container_base/depends/i686-pc-linux-gnu/include/mp/proxy-types.h:123:13), capnp::CallContext<ipc::capnp::messages::Echo::DestroyParams, ipc::capnp::messages::Echo::DestroyResults> &>' is deprecated: Use C++14 generalized captures instead. [-Werror,-Wdeprecated-declarations]
        kj::mvCapture(server_context.call_context,
            ^

maflcko · 2023-10-26T13:09:13Z

I presume the same warning will be printed when compiling with system packages on Debian Trixie? If yes, I guess it could make sense to somehow fix the warnings? cc @ryanofsky

ryanofsky · 2023-10-26T20:40:43Z

I presume the same warning will be printed when compiling with system packages on Debian Trixie? If yes, I guess it could make sense to somehow fix the warnings? cc @ryanofsky

Thanks for the PR. I created an issue bitcoin-core/libmultiprocess#87 to track the deprecation warnings, and can probably implement a quick fix. Fixing them in libmultiprocess will require bumping that package as well, so it might be preferable to just pass -Wno-error=deprecated-declarations here. It seems a little extreme to treat calls to deprecated functions as hard errors anyway.

maflcko · 2023-10-27T08:19:39Z

It seems a little extreme to treat calls to deprecated functions as hard errors anyway.

I think this is set in the CI, so that warnings are caught before they hit the users, who would otherwise then create issues that a local build on their system spits out warnings.
Also, this is set to be aware of warnings in CI builds that wouldn't occur locally. (Turning warnings into errors is the only way to surface them, because no one reads the logs of a green CI)

I'll leave this pull in draft for a while. If someone fixes bitcoin-core/libmultiprocess#87, I can pull it in here. If not, I'll undraft at some point and open this pull for review.

maflcko · 2023-11-01T07:59:33Z

Taken out of draft. Future improvements to chaincodelabs/libmultiprocess can be done in the future.

ryanofsky

Code review ACK fa7d837

ryanofsky · 2023-11-01T22:11:04Z

ci/test/00_setup_env_i686_multiprocess.sh

@@ -15,3 +15,4 @@ export GOAL="install"
 export BITCOIN_CONFIG="--enable-debug CC='clang -m32' CXX='clang++ -m32' \
 LDFLAGS='--rtlib=compiler-rt -lgcc_s' CPPFLAGS='-DBOOST_MULTI_INDEX_ENABLE_SAFE_MODE'"
 export TEST_RUNNER_ENV="BITCOIND=bitcoin-node"
+export NO_WERROR=1  # Temporary workaround to avoid -Wdeprecated-declarations from KJ


In commit "depends: Bump to capnproto-c++-1.0.1" (fa7d837)

I think setting -Wno-error=deprecated-declarations would be a little better.

Treating warnings as errors can be helpful since warnings often signal potential bugs. But treating deprecated declarations as errors is not the same, since deprecated declarations in capnproto suggest that the code works fine, but there's a just newer API available.

Not too important, though, since is easy to change libmultiprocess to avoid this warning while being backward compatible.

I agree, but I don't think there is an easy and recommended way to disable a single warning to not error. I could embed it into the compiler (CXX='clang++ -Wno-error=deprecated-declarations), but I presume this will be overridden by the configure logic to enable errors. I could set it in CXXFLAGS, but I presume this will either be overridden in the configure logic, or it will cause other horrible side-effects, such as disabling O2 (https://github.com/bitcoin/bitcoin/pull/28071/files).
Finally, I could patch the configure logic, but that seems overkill for a temporary workaround.

TheCharlatan

ACK fa7d837

hebasto · 2023-11-02T09:53:30Z

$ make -C depends capnp MULTIPROCESS=1 HOST=x86_64-w64-mingw32
make: Entering directory '/home/hebasto/git/bitcoin/depends'
Building capnp...
make[1]: Entering directory '/home/hebasto/git/bitcoin/depends/work/build/x86_64-w64-mingw32/capnp/1.0.1-f19a52e23f7'
make  all-am
make[2]: Entering directory '/home/hebasto/git/bitcoin/depends/work/build/x86_64-w64-mingw32/capnp/1.0.1-f19a52e23f7'
/bin/bash ./libtool  --tag=CXX   --mode=link x86_64-w64-mingw32-g++-posix -I./src -I./src -DKJ_HEADER_WARNINGS -DCAPNP_HEADER_WARNINGS -DCAPNP_INCLUDE_DIR='"/home/hebasto/git/bitcoin/depends/x86_64-w64-mingw32/include"' -mthreads -pipe -std=c++17 -O2 -mthreads -DKJ_USE_FIBERS -release 1.0.1 -no-undefined -L/home/hebasto/git/bitcoin/depends/x86_64-w64-mingw32/lib -o libkj.la -rpath /home/hebasto/git/bitcoin/depends/x86_64-w64-mingw32/lib src/kj/cidr.lo src/kj/common.lo src/kj/units.lo src/kj/memory.lo src/kj/refcount.lo src/kj/array.lo src/kj/list.lo src/kj/string.lo src/kj/string-tree.lo src/kj/source-location.lo src/kj/hash.lo src/kj/table.lo src/kj/encoding.lo src/kj/exception.lo src/kj/debug.lo src/kj/arena.lo src/kj/io.lo src/kj/mutex.lo src/kj/thread.lo src/kj/time.lo src/kj/filesystem.lo src/kj/filesystem-disk-unix.lo src/kj/filesystem-disk-win32.lo src/kj/test-helpers.lo src/kj/main.lo src/kj/parse/char.lo  
libtool: link: rm -fr  .libs/libkj.dll.a
libtool: link: x86_64-w64-mingw32-g++-posix -shared -nostdlib /usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/lib/dllcrt2.o /usr/lib/gcc/x86_64-w64-mingw32/10-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/10-posix -L/usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/lib -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/x86_64-w64-mingw32/10-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+0x1e5): undefined reference to `__imp_inet_ntop'
/usr/bin/x86_64-w64-mingw32-ld: src/kj/.libs/cidr.o:cidr.c++:(.text+0x467): undefined reference to `__imp_inet_pton'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1941: libkj.la] Error 1
make[2]: Leaving directory '/home/hebasto/git/bitcoin/depends/work/build/x86_64-w64-mingw32/capnp/1.0.1-f19a52e23f7'
make[1]: *** [Makefile:1525: all] Error 2
make[1]: Leaving directory '/home/hebasto/git/bitcoin/depends/work/build/x86_64-w64-mingw32/capnp/1.0.1-f19a52e23f7'
make: *** [funcs.mk:291: /home/hebasto/git/bitcoin/depends/work/build/x86_64-w64-mingw32/capnp/1.0.1-f19a52e23f7/./.stamp_built] Error 2
make: Leaving directory '/home/hebasto/git/bitcoin/depends'

fanquake · 2023-11-02T10:20:49Z

While we are changing this, could also add the following. I assume we don't use the TLS lib for anything, so we can skip the configure checks, and building the library if OpenSSL happens to be found:

--- a/depends/packages/native_capnp.mk
+++ b/depends/packages/native_capnp.mk
@@ -5,6 +5,10 @@ $(package)_download_file=capnproto-c++-$($(package)_version).tar.gz
 $(package)_file_name=capnproto-cxx-$($(package)_version).tar.gz
 $(package)_sha256_hash=0f7f4b8a76a2cdb284fddef20de8306450df6dd031a47a15ac95bc43c3358e09
 
+define $(package)_set_vars
+  $(package)_config_opts=--with-openssl=no
+endef
+
 define $(package)_config_cmds
   $($(package)_autoconf)
 endef

maflcko · 2023-11-02T11:20:37Z

make: *** [funcs.mk:291: /home/hebasto/git/bitcoin/depends/work/build/x86_64-w64-mingw32/capnp/1.0.1-f19a52e23f7/./.stamp_built] Error 2

I also tried 0.9.2, with another error:

# make capnp MULTIPROCESS=1 HOST=x86_64-w64-mingw32 
Building capnp...
make[1]: Entering directory '/bitcoin-core/depends/work/build/x86_64-w64-mingw32/capnp/0.9.2-e1454ca26e8'
make  all-am
make[2]: Entering directory '/bitcoin-core/depends/work/build/x86_64-w64-mingw32/capnp/0.9.2-e1454ca26e8'
depbase=`echo src/capnp/compiler/capnp.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
x86_64-w64-mingw32-g++-posix -DHAVE_CONFIG_H -I.   -I/bitcoin-core/depends/x86_64-w64-mingw32/include -I./src -I./src -DKJ_HEADER_WARNINGS -DCAPNP_HEADER_WARNINGS -DCAPNP_INCLUDE_DIR='"/bitcoin-core/depends/x86_64-w64-mingw32/include"' -mthreads -pipe -std=c++17 -O2 -mthreads -MT src/capnp/compiler/capnp.o -MD -MP -MF $depbase.Tpo -c -o src/capnp/compiler/capnp.o src/capnp/compiler/capnp.c++ &&\
mv -f $depbase.Tpo $depbase.Po
src/capnp/compiler/capnp.c++:27:10: fatal error: kj/win32-api-version.h: No such file or directory
   27 | #include <kj/win32-api-version.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:2307: src/capnp/compiler/capnp.o] Error 1
make[2]: Leaving directory '/bitcoin-core/depends/work/build/x86_64-w64-mingw32/capnp/0.9.2-e1454ca26e8'
make[1]: *** [Makefile:1500: all] Error 2
make[1]: Leaving directory '/bitcoin-core/depends/work/build/x86_64-w64-mingw32/capnp/0.9.2-e1454ca26e8'
make: *** [funcs.mk:291: /bitcoin-core/depends/work/build/x86_64-w64-mingw32/capnp/0.9.2-e1454ca26e8/./.stamp_built] Error 2

maflcko · 2023-11-02T11:51:39Z

The compile error also happens outside of depends, so I guess someone can report it upstream?

maflcko · 2023-11-02T12:55:33Z

Disabled openssl, should be easy to re-ACK

fanquake · 2023-11-03T11:24:15Z

so I guess someone can report it upstream?

capnproto/capnproto#1833

depends/packages/native_capnp.mk

DrahtBot · 2023-11-04T02:30:21Z

Guix builds (on x86_64)

File	commit `f23ac10` (master)	commit `0e574f7` (master and this pull)
SHA256SUMS.part	`92659357fc97fc8e...`	`43b7703e770f4e69...`
*-aarch64-linux-gnu-debug.tar.gz	`8e85af4277097e63...`	`29235d3f9effb21b...`
*-aarch64-linux-gnu.tar.gz	`d29c219e45146ed7...`	`0a89c13e8df65473...`
*-arm-linux-gnueabihf-debug.tar.gz	`e9564bc7151e514d...`	`6c2b9eecda144471...`
*-arm-linux-gnueabihf.tar.gz	`0dea490de2900729...`	`33478e33bab0c843...`
*-arm64-apple-darwin-unsigned.tar.gz	`ed905a38a6985922...`	`879657ce107d71c7...`
*-arm64-apple-darwin-unsigned.zip	`5ff300abccc86e16...`	`02e6453a10220fe4...`
*-arm64-apple-darwin.tar.gz	`a46b5b97c3daaad9...`	`b051fabec9a76a43...`
*-powerpc64-linux-gnu-debug.tar.gz	`ed88e835f99cd5cc...`	`35f177f845188f9c...`
*-powerpc64-linux-gnu.tar.gz	`0be7a7cb50a4dd4a...`	`66440f0797da891b...`
*-powerpc64le-linux-gnu-debug.tar.gz	`9565b3c366b349e0...`	`012f3b387426fa5e...`
*-powerpc64le-linux-gnu.tar.gz	`01c7d06acaa2bda9...`	`97b0b45388b31404...`
*-riscv64-linux-gnu-debug.tar.gz	`bcc048b2f5be12e1...`	`ceabaec402ce9c51...`
*-riscv64-linux-gnu.tar.gz	`e9b064d98292bf76...`	`6b9b0a5686693345...`
*-x86_64-apple-darwin-unsigned.tar.gz	`a0715a07c1dcf9d3...`	`38c2503d1425a706...`
*-x86_64-apple-darwin-unsigned.zip	`31b6d7106c930a54...`	`b3d7bcd1aa427bab...`
*-x86_64-apple-darwin.tar.gz	`5ab5018cc8162e08...`	`99524f8b9917f631...`
*-x86_64-linux-gnu-debug.tar.gz	`250b3ad75c897648...`	`8e549faead23ec86...`
*-x86_64-linux-gnu.tar.gz	`2011c32866473392...`	`76f76710d25ca458...`
*.tar.gz	`2ea368703376018d...`	`20b85b23137c689b...`
guix_build.log	`cb9055f69265de9e...`	`2b27afb1388a3808...`
guix_build.log.diff		`37639fc82069bc71...`

ryanofsky

Code review ACK 3333f14

Am wondering if we know why the guix build succeeds and CI passes if the ubuntu mingw build fails manually. Is that expected? Would it make any sense to change what platforms CI covers, or is the failing build platform pretty close to the ones that succeed and the failure is just a quirk?

maflcko · 2023-11-05T17:36:53Z

I don't think the CI win64-cross build has multiprocess enabled. There is only one non-windows one (multiprocess, i686, DEBUG). Also, I don't think guix has multiprocess enabled, and probably won't have it enabled until at least mid-next year. Anyone is welcome to fix the win64-cross multiprocess build, and even enable it in CI or guix, if they want to.

ryanofsky · 2023-11-05T19:59:21Z

I don't think the CI win64-cross build has multiprocess enabled

Thanks, I forgot it would only be built if that flag is enabled

ryanofsky · 2023-11-17T20:23:18Z

depends/packages/native_libmultiprocess.mk

@@ -1,8 +1,8 @@
 package=native_libmultiprocess
-$(package)_version=1af83d15239ccfa7e47b8764029320953dd7fdf1
+$(package)_version=61d5a0e661f20a4928fbf868ec9c3c6f17883cc7


I think it probably wasn't required to bump libmultiprocess at the same time as bumping capnproto, but good to do it anyway since to provide test coverage for newer code. Changes in the bump were:

Install Exports for custom install-{lib,bin} targets bitcoin-core/libmultiprocess#79

Introduce clang-tidy and optimize code bitcoin-core/libmultiprocess#83

Avoid passing some function arguments by value bitcoin-core/libmultiprocess#84

Remove naming requirement for std::pair/std::tuple bitcoin-core/libmultiprocess#85

Add support for vector<bool> serialization bitcoin-core/libmultiprocess#86

bitcoin-core/libmultiprocess@1af83d1...61d5a0e

This incorporates PR bitcoin-core/libmultiprocess#88 "Fix current deprecation warnings as of capnproto-1.0.1" and reverts the NO_WERROR CI workaround added in bitcoin#28735

ryanofsky · 2023-11-17T23:09:42Z

PR description lists a few reasons for bumping the capnproto version, but it doesn't actually mention the original motivation, which was to fix a C++20 compiler issue: #28349 (comment), capnproto/capnproto#1618. Just wanted to note this explicitly

…ion warnings 21bfee0 depends: bump libmultiprocess to fix capnproto deprecation warnings (Ryan Ofsky) Pull request description: This incorporates PR bitcoin-core/libmultiprocess#88 and reverts the NO_WERROR CI workaround added in #28735 Upstream diff: bitcoin-core/libmultiprocess@61d5a0e...414542f --- This PR is part of the [process separation project](#28722). ACKs for top commit: maflcko: lgtm ACK 21bfee0 hebasto: ACK 21bfee0, 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

…apnp` packages with CMake 11d797e depends: Build `native_capnp` package with CMake (Hennadii Stepanov) 90389c9 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 @ 160d236: - for `x86_64-w64-mingw32` (see bitcoin/bitcoin#28735 (comment)): ``` 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](bitcoin/bitcoin#28856 (comment)). ACKs for top commit: ryanofsky: Code review ACK 11d797e. 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

This incorporates PR bitcoin-core/libmultiprocess#88 "Fix current deprecation warnings as of capnproto-1.0.1" and reverts the NO_WERROR CI workaround added in bitcoin/bitcoin#28735

BACKPORT NOTICE: excludes ci/test/00_setup_env_i686_multiprocess.sh changes, however, these do not satisfy enough this to be partial to me 3333f14 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 3333f14 fanquake: ACK 3333f14 - the response from upstream is that [if we submit a PR, they can take a look](capnproto/capnproto#1833 (comment)), so if anyone would like this to work for Windows, I'd suggest sending a patch. ryanofsky: Code review ACK 3333f14 Tree-SHA512: 7d53ad1536f042ab43dbc7847126b826e7fc76694f173c348b835fd1067b8f3dd682c5bcb4887f09ee85bab69130721cd7f8fb96b2e82053d4e28bd5c38bdc5f

…eprecation warnings 21bfee0 depends: bump libmultiprocess to fix capnproto deprecation warnings (Ryan Ofsky) Pull request description: This incorporates PR bitcoin-core/libmultiprocess#88 and reverts the NO_WERROR CI workaround added in bitcoin#28735 Upstream diff: bitcoin-core/libmultiprocess@61d5a0e...414542f --- This PR is part of the [process separation project](bitcoin#28722). ACKs for top commit: maflcko: lgtm ACK 21bfee0 hebasto: ACK 21bfee0, 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