[RFC] ipc: Check / enforce exception support #36058

When configured with -DENABLE_IPC=ON, the Bitcoin Core codebase expects the underlying KJ library to be built with exception support. If it is not, the interface_ipc.py and interface_ipc_mining.py functional tests fail, as shown in https://github.com/hebasto/bitcoin-core-nightly/actions/runs/32576370006/job/97039239853. When this behavior is not set explicitly via the KJ_NO_EXCEPTIONS macro, it is autodetected in the c++/src/kj/common.h header.

Instead of relying on autodetection, it seems reasonable to:

1. Check that all related dependencies, including the kj and capnproto libraries, are built with exception support.

2. Enforce exception support in depends/packages/capnp.mk.

3. Enforce exception support for the targets in src/ipc/libmultiprocess/.

For more details, see https://github.com/capnproto/capnproto/pull/2756.

Draft PR for the three items: #36060

I put the check in Core cmake so we don't touch the libmultiprocess subtree. Finding libkj from the parent isn't great; I can move the check into libmultiprocess if that's preferable.

KJ_NO_EXCEPTIONS=0 on Core does not rebuild libkj. Configure fails when the library was built without exception support.

cc @ryanofsky @Sjors

That sounds reasonable to me. Exceptions are expected, so it's not just about breaking functional tests.

Description of the proposed changes is a little vague, but I don't think most of the changes in #36060 currently make sense.

34201d5fb0274cbe89a2d6ea67d8221930dd7e8c which corresponds to suggestion 1 here seems very complicated. I do think it's good to detect problems at compile time but I think a simpler solution like https://github.com/bitcoin-core/libmultiprocess/pull/364 would be better.

4f71358ccbbe789bd26b87153e946e2390fe4eeb seems to correspond to suggestion #2 here. It is setting -DKJ_NO_EXCEPTIONS=0 depends without an explanation of why it being set, apparently due to a bug that only happens in the netbsd packaging system https://github.com/capnproto/capnproto/pull/2756 that doesn't happen in depends.

68bee5832cd8bc21c928ac7e3c27dc7673424362 has a little more justification than 4f71358ccbbe789bd26b87153e946e2390fe4eeb because it at least does work around a bug that can happen in reality. But I'm not sure it is worth the complexity if capnproto bug https://github.com/capnproto/capnproto/pull/2756 is already fixed upstream and there is a clear error and manual workaround for netbsd users in the meantime.

Note: It would also help to link to https://github.com/capnproto/capnproto/pull/2756 in the issue description otherwise the CI failure linked there doesn't make a lot of sense. (I wasted some time trying to debug it.)

Note: It would also help to link to capnproto/capnproto#2756 in the issue description otherwise the CI failure linked there doesn't make a lot of sense. (I wasted some time trying to debug it.)

Thanks! Added.