CMake 4.1.0+ fails to configure cross-build for macOS with Ninja generator

hebasto commented at 1:25 pm on February 5, 2026: member

When cross-compiling for macOS on Linux, the configuration step fails when using the Ninja generator:

 0$ gmake -j $(nproc) -C depends HOST=x86_64-apple-darwin NO_QT=1
 1$ cmake -B build -G Ninja --toolchain depends/x86_64-apple-darwin/toolchain.cmake
 2<snip>
 3CMake Error at src/CMakeLists.txt:301 (add_executable):
 4  The install of the bitcoind target requires changing an RPATH from the
 5  build tree, but this is not supported with the Ninja generator unless on an
 6  ELF-based or XCOFF-based platform.  The CMAKE_BUILD_WITH_INSTALL_RPATH
 7  variable may be set to avoid this relinking step.
 8
 9
10<snip>

This behavior is observed with CMake starting from version 4.1.0.

This issue does not occur when building with depends on macOS.

hebasto added the label macOS on Feb 5, 2026

hebasto added the label Build system on Feb 5, 2026

hebasto commented at 1:25 pm on February 5, 2026: member

cc @purpleKarrot

fanquake commented at 1:29 pm on February 5, 2026: member

What is there for us to do here that isn’t explained in the error output?

purpleKarrot commented at 2:33 pm on February 5, 2026: contributor

The output message hints that there are two options to avoid the limitation:

Use a different generator, like “Unix Makefiles”, to make the build slow.
Set the CMAKE_BUILD_WITH_INSTALL_RPATH variable to avoid the relinking step but potentially break unit tests because objects are no longer found.

But there is a third option: Remove the need for changing the RPATH in the first place (by not setting CMAKE_INSTALL_RPATH). What is this needed for? It was introduced in #20046, maybe @ryanofsky can explain what this setting was intended to fix (the issue mentions it as a fix for “not working”).

fanquake commented at 2:37 pm on February 5, 2026: member

Looks like our upstream question never got any reply: https://discourse.cmake.org/t/install-rpath-use-link-path-not-working-when-cmake-exe-linker-flags-ldflags-is-set/1892.

purpleKarrot commented at 3:13 pm on February 5, 2026: contributor

The upstream issue aside, we should just make sure that a workaround for making mpgen usable at build time does not affect the RPATH in binaries that are shipped to clients, such as bitcoind.

fanquake commented at 3:20 pm on February 5, 2026: member

Our release binaries are built with CMAKE_SKIP_RPATH, which should prevent any RPATH information from being added (we also check that the binaries do not have any rpath or runpath information).

ryanofsky commented at 3:20 pm on February 5, 2026: contributor

Remove the need for changing the RPATH in the first place

I’m not sure the reason cmake wants to relink mpgen before installing it, so I would expect CMAKE_BUILD_WITH_INSTALL_RPATH to work and not break anything, but I could be missing something.

For background on the current code: mpgen has the INSTALL_RPATH_USE_LINK_PATH property enabled because it depends on cap’nproto shared libraries, so needs the rpath to find them if they aren’t on the normal runtime search path.

https://github.com/bitcoin/bitcoin/blob/eb97250421d35f8c172d43b69965af6273025702/src/ipc/libmultiprocess/CMakeLists.txt#L206-L207

Additionally, since #20046, the depends system has also been setting CMAKE_INSTALL_RPATH in native package builds to work around a (possibly buggy) behavior in cmake where setting the LDFLAGS environment variable caused INSTALL_RPATH_USE_LINK_PATH to be ignored. This is the problem reported https://discourse.cmake.org/t/install-rpath-use-link-path-not-working-when-cmake-exe-linker-flags-ldflags-is-set/1892.

https://github.com/bitcoin/bitcoin/blob/eb97250421d35f8c172d43b69965af6273025702/depends/funcs.mk#L230-L232

It’s possible the latter issue no longer exists and we could drop the CMAKE_INSTALL_RPATH setting from depends. Or maybe depends should be setting CMAKE_BUILD_WITH_INSTALL_RPATH alongside CMAKE_INSTALL_RPATH. Unclear if those changes would fix this issue though because the relinking step here seems to be happening in the bitcoin build, not the depends build. I also don’t understand what exactly causes cmake to decide it needs a relinking step, or if a reiinking step is actually needed here.

ryanofsky commented at 3:34 pm on February 5, 2026: contributor

The upstream issue aside, we should just make sure that a workaround for making mpgen usable at build time does not affect the RPATH in binaries that are shipped to clients, such as bitcoind.

In addition to what fanquake wrote, this should also not be an issue becuase INSTALL_RPATH_USE_LINK_PATH is only set on the mpgen target which is not distributed, and CMAKE_INSTALL_RPATH is only set by depends on native packages providing build-time tools, not on host packages providing runtime dependencies.

ryanofsky commented at 4:03 pm on February 5, 2026: contributor

Thinking about this more, I think reported issue is probably unrelated to use of INSTALL_RPATH_USE_LINK_PATH / CMAKE_INSTALL_RPATH settings. Former is only set on mpgen target so I don’t think it should trigger the reported error about bitcoind. Latter is only set inside depends cmake package builds for native executable tools, so should not affect the top-level bitcoin build.

So I think fanquake’s initial reaction that there probably isn’t anything for us to do here seems right. If this issue started happening with cmake 4.1.0, maybe it is a new bug or limitation of that cmake version. It is unclear why cmake thinks “The install of the bitcoind target requires changing an RPATH” when it doesn’t seem like this should be true.

maflcko added the label Upstream on Feb 5, 2026

fanquake commented at 9:52 am on February 9, 2026: member

If this issue started happening with cmake 4.1.0, maybe it is a new bug or limitation of that cmake version.

Yea. I’d think the first thing to look at would be the release notes for that version, as I’d a assume a change in behaviour like this would be documented. If not, maybe another issue can be opened upstream.

fanquake commented at 11:50 am on February 10, 2026: member

I also cannot recreate this issue using the steps provided, and CMake 4.2.3:

0gmake -j15 -C depends HOST=x86_64-apple-darwin NO_QT=1
1cmake -B build -G Ninja --toolchain depends/x86_64-apple-darwin/toolchain.cmake
2cmake --build build -j15

Works fine, building on arm64 macOS.

hebasto commented at 9:00 am on February 11, 2026: member

I also cannot recreate this issue using the steps provided, and CMake 4.2.3:

gmake -j15 -C depends HOST=x86_64-apple-darwin NO_QT=1 cmake -B build -G Ninja –toolchain depends/x86_64-apple-darwin/toolchain.cmake cmake –build build -j15

Works fine, building on arm64 macOS.

Right, the issue only manifests when building on Linux.

fanquake commented at 9:04 am on February 11, 2026: member

only manifests when building on Linux.

Can you put all of the relevant information, and required steps into the issue description. As well as test with the latest available version of CMake?

hebasto renamed this:
~~CMake 4.1.0 fails to configure cross-build for macOS with Ninja generator~~
CMake 4.1.0+ fails to configure cross-build for macOS with Ninja generator
on Feb 11, 2026

hebasto commented at 9:58 am on February 11, 2026: member

only manifests when building on Linux.

Can you put all of the relevant information, and required steps into the issue description. As well as test with the latest available version of CMake?

Updated.

The issue is caused by this code:https://github.com/bitcoin/bitcoin/blob/fd625d84ae9e73cb2ce98cceca199ed831d8b0f4/CMakeLists.txt#L72-L76

fanquake commented at 11:10 am on February 11, 2026: member

The issue is caused by this code:

That code has existed since we migrated to CMake, so it looks like you’ll need to investigate what has changed upstream, to now cause this change in behaviour.

hebasto commented at 6:10 pm on February 13, 2026: member

The issue is caused by this code:

That code has existed since we migrated to CMake, so it looks like you’ll need to investigate what has changed upstream, to now cause this change in behaviour.

Bisecting pointed at commit eb8facd39606e9472f9ff6de40d7caf76767d0da from [MR #10721](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/10721).

cc @purpleKarrot

fanquake commented at 12:12 pm on February 20, 2026: member

From what I can tell, this doesn’t effect 30.x?

hebasto commented at 12:40 pm on February 20, 2026: member

From what I can tell, this doesn’t effect 30.x?

True.

CMake 4.1.0+ fails to configure cross-build for macOS with Ninja generator #34513