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 https://github.com/maflcko/bitcoin-core-nightly/issues/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.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process. A summary of reviews will appear here.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
support branch for CI scripts, documentation, and examples 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.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
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 (https://github.com/maflcko/bitcoin-core-nightly/issues/14#issuecomment-4632269615) 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.
Fair enough. Closing.
Thanks and to be sure I don't object to this change if it's documented properly either as a workaround or as a reasoned design decision to override cmake's default treatment of the PATH variable. I just want to avoid special cases in the build scripts that could make them hard to maintain & safely modify.