Cap'n Proto 0.9 & 0.10 capnp/blob.h error: invalid operands to binary expression ('const char *' and 'kj::StringPtr')

ryanofsky commented at 1:56 pm on September 1, 2025: collaborator

Cap’n Proto versions 0.9.x and 0.10.x are incompatible with clang 16 and later when -std=c++20 is used, causing error:

0/usr/include/capnp/blob.h:176:74: error: invalid operands to binary expression ('const char *' and 'kj::StringPtr')

This was reported by willcl-ark in #194 (comment) and maflcko in #194 (comment)

This error can be avoided by any of the following:

Upgrading to Cap’n Proto version 1.0 or newer which fixed this in capnproto/capnproto#1618, or applying the patch as done in shell.nix.
Downgrading to Cap’n Proto version 0.8 or earlier, before capnproto/capnproto#1170 which triggers this issue starting in version 0.9.
Downgrading to clang-15 or earlier, before P2468R2 which triggers this issue starting in version 16.
Maybe using GCC (not sure what the status of this is with GCC)

Background

Libmultiprocess only uses basic Cap’n Proto features, and for the most part doesn’t rely on its c++20 behavior, though it did recently work around a c++20 GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499 in #194
Cap’n Proto started to improve it’s C++20 support in capnproto/capnproto#1170 and capnproto/capnproto#1235 which were both included in version 0.9.0. But unfortunately these changes stopped working well when clang-16 was released because it implemented P2468R2.
P2468R2 caused the compiler to stop generating reversed operator==(U,T) comparisons from operator==(T,U) if an operator!=(T,U) comparison was declared.
This issue was fixed in capnproto/capnproto#1618, and the fix was expanded in capnproto/capnproto#1733. Both of these changes are included in Cap’n Proto versions 1.0 and later.

maflcko commented at 2:26 pm on September 1, 2025: contributor

Downgrading to clang-15 or earlier, before P2468R2 which triggers this issue starting in version 16.

That doesn’t work with Bitcoin Core, which requires clang-16.

Maybe -DENABLE_IPC=OFF can be set temporarily for the 30.x release branch, only enabling it in depends (and thus the release binaries) by default for now? Though, I am not sure how many people are using Ubuntu Jammy (with system capnproto 0.8) or Debian Bookworm with clang.

ryanofsky commented at 2:53 pm on September 1, 2025: collaborator

We could change ENABLE_IPC default, and there’s been a lot of discussion about what this default should be in https://github.com/bitcoin/bitcoin/pull/31802, https://github.com/bitcoin/bitcoin/pull/33190, and https://github.com/bitcoin/bitcoin/pull/33235.

The thing I’d like most like to do is make sure build-unix.md instructions work out of the box by default, and update them to mention incompatibilities if certain package versions won’t work together. It looks like the Ubuntu Jammy and Debian Bookworm incompatibilities should both be mentioned, though I’m not clear whether the debian one is a clang-only issue or if it happens with gcc

ryanofsky commented at 3:09 pm on September 1, 2025: collaborator

Another thing that could be nice to do in both cases is improve the build error messages and have them link to relevant issues and suggest using -DENABLE_IPC=OFF as a workaround if IPC features are not needed.

willcl-ark referenced this in commit ee5e284cca on Sep 2, 2025

willcl-ark commented at 8:20 pm on September 2, 2025: member

Thanks for investigating ryanofsky.

Another thing that could be nice to do in both cases is improve the build error messages and have them link to relevant issues and suggest using -DENABLE_IPC=OFF as a workaround if IPC features are not needed.

I tested a commit in my debian:bookwork/clang-19 container which prints a more helpful error message based on OP when this combination of packages are detected: https://github.com/bitcoin-core/libmultiprocess/compare/master...willcl-ark:libmultiprocess:clang-capnp-incompat

I also tested briefly that gcc works, but not sure about adding bitcoin core-specific references to libmultiprocess (I see only a few currently). I think it’s helpful to document the ENABLE_IPC=OFF specifically though.

This approach seems to work ok, and feels reasonable-enough to me that it might not require amending the build-unix.md notes.

ryanofsky commented at 8:39 pm on September 2, 2025: collaborator

Thanks @willcl-ark! If you could create a PR from that branch, I think it’d be helpful and good to merge. I was actually imagining a different approach using try_compile to detect the bug and maybe checking whether an ENABLE_IPC option was defined, but your commit seems simpler and might be more reliable.

Also you may be right that if build feedback is clear enough, maybe build-unix.md doesn’t need to mention the incompatibilities, though it could still be reasonable to provide a short mention and link to issues in the Ubuntu & Debian section.

willcl-ark referenced this in commit 197aef2e2b on Sep 4, 2025

willcl-ark referenced this in commit d314057775 on Sep 4, 2025

ryanofsky referenced this in commit 13424cf2ec on Sep 5, 2025

fanquake commented at 9:36 am on September 8, 2025: member

Was this completely closed by #205? cc @willcl-ark

ryanofsky commented at 9:47 am on September 8, 2025: collaborator

Yeah, I think this can be closed with #205 since it catches the problem earlier and suggests workarounds to avoid it.

One workaround listed above it doesn’t suggest is applying the bugfix as a patch, but that should be fine.

ryanofsky closed this on Sep 8, 2025

Cap’n Proto 0.9 & 0.10 capnp/blob.h error: invalid operands to binary expression (‘const char *’ and ‘kj::StringPtr’) #199

Background