Repository navigation
[CMake] Generate darwin std modulemap from the libc++ of the compiler - #23923
Merged
Merged
Conversation
guitargeek
force-pushed
the
darwin-modules
branch
from
October 30, 2026 18:51
36f4fb1 to
4e4b287
Compare
Test Results 22 files 22 suites 3d 15h 22m 1s ⏱️ Results for commit 2bd42df. ♻️ This comment has been updated with latest results. |
vepadulano
reviewed
Nov 2, 2026
guitargeek
force-pushed
the
darwin-modules
branch
2 times, most recently
from
November 2, 2026 12:26
11e2b07 to
99abb89
Compare
guitargeek
added a commit
to guitargeek/nixpkgs
that referenced
this pull request
Nov 2, 2026
…ules workaround Update to the current head of ROOT PR 23877. The fix for the openui5 install rule is part of the PR now. The compiledata.sh and cling include directory fixes were upstreamed as root-project/root@1b6d33beb82 and root-project/root#23924, so fetch them from there instead of carrying local copies. Also apply root-project/root#23923, which generates the Darwin std modulemap from the libc++ of the compiler instead of the one in the SDK. This was the reason for disabling runtime_cxxmodules on Darwin.
guitargeek
added a commit
to guitargeek/nixpkgs
that referenced
this pull request
Nov 2, 2026
ROOT PR 23877 is merged, so take the sources from root-project/root master instead of the feature branch. Master renamed the JSROOT archive to jsroot-7.12.0.tar.gz, so adjust the pre-downloaded archive and regenerate the ROOT_DOWNLOAD_DIR patch against it. The compiledata.sh fix is in master as well, so drop it. The Darwin modulemap fix is taken as the two commits of root-project/root#23923.
With runtime_cxxmodules on macOS, the build generates std_darwin.modulemap by wrapping the libc++ module map, which it looks up in the SDK at "<CMAKE_OSX_SYSROOT>/usr/include/c++/v1". That is not necessarily the libc++ that is actually used: toolchains like Homebrew LLVM, Nix or conda-forge ship their own libc++ next to the compiler, and the SDK can be stripped of libc++ altogether (conda-forge and Nix do that), in which case the configuration fails with: FileNotFoundError: Cannot find libc++ modulemap at <SDK>/usr/include/c++/v1/module.modulemap The generated module map must match the libc++ that cling uses at runtime, which is the one of the compiler: cling queries the compiler for its C++ include directory and mounts std_darwin.modulemap there. Hence, look for the libc++ include directory in the implicit include directories of the compiler (identified by the "__config" header and a module map) and hand it to the script, which prefers it over the SDK path. For the default Apple toolchain, the implicit include directories contain the libc++ of the SDK, so nothing changes there. The existing fallbacks are kept. Also make the generated modulemap depend on the libc++ modulemap it is derived from, so that it is regenerated when the toolchain is updated in place (e.g. the Command Line Tools SDK). 🤖 Done with the help of AI
guitargeek
force-pushed
the
darwin-modules
branch
from
November 3, 2026 08:42
99abb89 to
2bd42df
Compare
Contributor
Author
|
@vepadulano, I have reverted this PR to only contain the original commit, and opened a draft PR with the conda-related change so we don't forget about it: #23962 |
vepadulano
reviewed
Nov 3, 2026
bellenot
approved these changes
Nov 3, 2026
Contributor
Author
|
/backport to 6.42 |
|
Preparing to backport PR #23923 to branch 6.42 requested by guitargeek |
|
This PR has been backported to branch 6.42: #23969 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With runtime_cxxmodules on macOS, the build generates std_darwin.modulemap by wrapping the libc++ module map, which it looks up in the SDK at "<CMAKE_OSX_SYSROOT>/usr/include/c++/v1". That is not necessarily the libc++ that is actually used: toolchains like Homebrew LLVM, Nix or conda-forge ship their own libc++ next to the compiler, and the SDK can be stripped of libc++ altogether (conda-forge and Nix do that), in which case the configuration fails with:
FileNotFoundError: Cannot find libc++ modulemap at /usr/include/c++/v1/module.modulemap
The generated module map must match the libc++ that cling uses at runtime, which is the one of the compiler: cling queries the compiler for its C++ include directory and mounts std_darwin.modulemap there. Hence, look for the libc++ include directory in the implicit include directories of the compiler (identified by the "__config" header and a module map) and hand it to the script, which prefers it over the SDK path. For the default Apple toolchain, the implicit include directories contain the libc++ of the SDK, so nothing changes there. The existing fallbacks are kept.
Also make the generated modulemap depend on the libc++ modulemap it is derived from, so that it is regenerated when the toolchain is updated in place (e.g. the Command Line Tools SDK).
🤖 Done with the help of AI