-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Use libc++
headers from macOS SDK instead of from clang
#18072
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
Conversation
We modify the macdeploy instructions in the next commit to include libc++ headers in the SDK.
Previously, we did not include the libc++ headers in our SDK creation, now we can use tpoechtrager's script to correctly do that. The gen_sdk_package.sh is taken from https://github.com/tpoechtrager/osxcross/blob/d3392f4eae78f3fa3f1fd065fa423f2712825102/tools/gen_sdk_package.sh The location within the SDK where we place the libc++ headers is chosen such that clang's search path detection logic for sysroots would pick up the headers properly. We also document this change.
adf9968
to
8e8fadf
Compare
Can you explain why this is useful? |
@sipa I apologize for not including that, it is now included in the PR description! |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
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. |
Travis linter is annoyed by a few things: https://travis-ci.org/github/bitcoin/bitcoin/jobs/646483250#L370 It wasn't super clear you have to point it to
The script produces a 97M file:
(assuming this is deterministic, maybe add that checksum to the script as a sanity check?) |
🐙 This pull request conflicts with the target branch and needs rebase. |
Closing in favor of: #19240 |
Based on #16392Update: Base PR has been merged.Why this is useful: Previously, we were using the
libc++
headers copied from the clang package we downloaded from llvm.org. This is suboptimal as our goal is to have a toolchain that can target macOS, which (in Xcode.app) has its own set oflibc++
headers that can differ from those of the clang package. It seems to me that given our goal, it is better to use what Apple intends, and not rely on upstreamclang
<-> Appleclang
compatibility.This requires a regeneration of the macOS SDK, I apologize that this didn't make it into #16392, please follow the updated instructions here: 8e8fadf?short_path=9de36be#diff-9de36befe13356841c2699ee0eff4a0a (I'm linking to the Markdown diff so that people who need to regenerate the macOS SDK can see the difference in procedure from before)