-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cling] Fix build with MacOSX15.0.sdk
#15900
Conversation
Manually curating the modulemap is far from ideal because it requires updates for changes in the libc++ library shipped with the SDK, which must also work across all supported SDK versions. An alternative would be to locate the modulemap shipped with libc++ during configuration time, copy it and dynamically modify its contents to suit our needs.
@PetroZarytskyi, can you help out with the Clad issue here? We probably fail to find the propagator for __builtin_pow. cc: @vaithak. |
It seems the From that point of view, the build fixes are complete. Note that the backport still needs to be synchronized to https://github.com/root-project/llvm-project/ before merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm!
Test Results 13 files 13 suites 2d 21h 44m 40s ⏱️ Results for commit fbc9348. ♻️ This comment has been updated with latest results. |
When an include from a textual header is resolved, the textual header's submodule is used as the requesting module. The submodule's uses are resolved, but that doesn't work because only top level modules have uses, and only the top level module uses are used for checking uses in Module::directlyUses. ModuleMap::resolveUses to resolve the top level module instead of the submodule. --- This fixes the build of std.pcm with MacOSX15.0.sdk.
The failures are unrelated and most likely due to a glitch in the EOS based file server. |
I propose to:
OK with everybody @hahnjo @vgvassilev ? |
Irrespective of the plan above or any modification to it, I believe we should sit down and understand how to deploy an automated way to build the module map. For example, internal headers will always be changed and it will be harder and harder to keep present versions of the sdk working and fix new ones. |
Makes sense. Could you also open a bug report and assign me on it? |
I decided to merge this PR as-is;
Agreed; let's wait for the PR above to be merged and then we can backport the two (edit: #15911).
We'll need to test how LLVM 13 in general behaves for the new SDK. I can hopefully do this today. |
Done: #15912 |
Remove some headers from
std_darwin.modulemap
and backport llvm/llvm-project@09ec000 to fix the build ofstd.pcm
.This fixes the build but still has five failing tests:
There seem to be at least two problems: an
UNREACHABLE executed
and Clad not being able to differentiate
__builtin_pow
:I'm still investigating, starting with the first.