Skip to content

cmake: Skip PATH environment variable when discovering CapnProto#290

Closed
hebasto wants to merge 1 commit into
bitcoin-core:masterfrom
hebasto:260605-capnp-path
Closed

cmake: Skip PATH environment variable when discovering CapnProto#290
hebasto wants to merge 1 commit into
bitcoin-core:masterfrom
hebasto:260605-capnp-path

Conversation

@hebasto
Copy link
Copy Markdown
Member

@hebasto hebasto commented Jun 5, 2026

On systems with UsrMerge, the PATH environment variable can cause CMake to produce include paths that contain root-level symlinks. The capnp compiler resolves paths lexically and fails to process them properly, resulting in a "no such directory" error.

Fixes maflcko/bitcoin-core-nightly#14.

CI runs in Bitcoin Core repo: https://github.com/hebasto/bitcoin/actions/runs/27019344100/job/79742757484.

On systems with UsrMerge, the `PATH` environment variable can cause
CMake to produce include paths that contain root-level symlinks. The
`capnp` compiler resolves paths lexically and fails to process them
properly, resulting in a "no such directory" error.
@DrahtBot
Copy link
Copy Markdown

DrahtBot commented Jun 5, 2026

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

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #288 (Create support branch for CI scripts, documentation, and examples by ryanofsky)
  • #276 (build: prepare for subtree split by Sjors)
  • #274 (Add nonunix platform support by ryanofsky)
  • #209 (cmake: Increase cmake policy version by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@ryanofsky
Copy link
Copy Markdown
Collaborator

So the problem on these systems is that find_package detects capnproto in /lib64/cmake/CapnProto and constructs the include path /lib64/cmake/CapnProto/../../../include.

Both of these paths are valid and resolve to /usr/lib64/cmake/CapnProto and /usr/include respectively by the operating system because /lib64 is a symlink to /usr/lib64

The problem is that capnproto is not using the operating system to resolve the include path. Instead it tries to simplify the include path lexically, resulting in /include which doesn't exist, instead of /usr/include which is what it actually resolves to. This is a bug in capnproto, because it's invalid to just drop path components followed by /.. when symlinks are involved. You have to resolve symlinks first, then drop path components. It sounds like a bug that should be reported and fixed in capnproto.

Trying to work around in this libmultiprocess is a hack because libmultiprocess is not involved in constructing or interpreting these paths. The fix is also fragile. It's interesting that CMake locates the package in /lib64/cmake/CapnProto if NO_SYSTEM_ENVIRONMENT_PATH is not specified, and /usr/lib64/cmake/CapnProto otherwise but it is fragile to rely on this behavior since both paths are valid and it seems like /ib64 could wind up being searched any number of ways even if PATH search is disabled.

It also seems like users can fix this by setting PATH variables more sanely (maflcko/bitcoin-core-nightly#14 (comment)) to point to real directories instead of /bin and /sbin symlinks created for backwards compatibility. Or to at least order the symlinks after the real directories.

If we want to address this issue at all in libmultiprocess, i think the think to do would be detect when CAPNP_INCLUDE_DIRECTORY can't be resolved lexically and recommend users fix their PATH or use -DCMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH=OFF as a workaround.

But this seems like something that should be resolved by users of these systems or by capnproto, not something libmultiprocess should be involved with.

@hebasto
Copy link
Copy Markdown
Member Author

hebasto commented Jun 5, 2026

@ryanofsky

Fair enough. Closing.

@hebasto hebasto closed this Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OpenSuse 16 Leap capnp issue

3 participants