ci: enable IPC in the i686 job #36679

Enable IPC on 32-bit x86. It was chosen arbitrarily in #31802 to have coverage for -DENABLE_IPC=OFF, but this was not a good choice given issues like:

• https://github.com/bitcoin-core/libmultiprocess/pull/383

I could not find a good candidate CI configuration to disable IPC.

It's still disabled on Windows, until #32387. It's also disabled on RISC-V.

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--006a51241073e994b41acfe9ec718e94-->

External sites

• Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36679
• Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36679.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36679#author-ralph

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

To retain coverage for more build permutations, we could introduce something like STAGED_CONFIG="-DENABLE_IPC=OFF" which builds with that additional option first, and then rebuilds without it.

Do you recall if this ci config piece ever failed? Recall we don't have any ci for NO_ZMQ=1 either.

Otherwise, lgtm ACK 65ddcb4f35c5fd315ecb9d9a6d0f076b37edcadd

The changes here should be fine since 0136e17c0a963e82bf47c223d41f4d5c009520c0

@maflcko I don't remember, but my agent found a few examples from before #31802:

Yes, it used to run as i686_multiprocess, and it had intermittent failures. Some were real IPC bugs, notably #31151’s shutdown race, fixed through #31740. Others were test flakes, such as the P2P-thread shutdown timeout fixed in #29933. There was also #31772’s mixed GCC/Clang ABI failure with depends at -O0, worked around in #31998. So I agree that 0136e17 is relevant.

Sorry, I think I wasn't clear. I agree that mixed gcc+clang coverage on 32-bit is useless, given that there is likely no user for it and given that the ABI failures are likely only possible to fix with an ABI break in upstream capnp, which is isn't going to happen, or at least seems too tedious to be worth it.

My question was if there was ever a CI failure due to -DENABLE_IPC=OFF. I presume those would only be build issues, like a link error? I don't recall one, so I think this change is fine to do.

Not that I recall either (the agent found #32297#pullrequestreview-2779056673). In general we've occasionally had build failures creep in when an option was uncovered by CI.

Most would be caught by Windows and RISC-V builds, but e.g. src/ipc/stub.cpp is not used by RISC-V (because it's EXCLUDE_FROM_ALL).

Ah, good bot. So it is mostly functional test failures and they'll be caught by Windows. If we want -DENABLE_IPC=OFF in the future, I think there are two options:

• Set -DENABLE_IPC=OFF in the musl ci config (It should be unlikely there is a musl-libc-specific issue in ipc, given that we never had a musl libc issue at all?)
• Edit: Given that the quoted issues above are about the cli, There could be a new ci config, with -DENABLE_IPC=OFF, possibly unit tests, bench, and the gui and zmq could be skipped. Thus, no-IPC and CLI can be run in the functional tests.

But not a blocker, just thinking for the future.

It should be unlikely there is a musl-libc-specific issue in ipc

We just had #35491.

given that we never had a musl libc issue at all?

We just had #36045.

Thx for finding those. Edit: I guess in that case a new dedicated -DENABLE_IPC=OFF ci config makes most sense to catch the build issues, but leave coverage up in all other ci tasks?

I won't block this, but as expressed before, I don't think pretending like we fully support 32 bit architectures is the best use of our time, see https://github.com/bitcoin/bitcoin/issues/36659

cc @ryanofsky - if you've got any thoughts here.