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
depends: Pin clang search paths for darwin host #19683
depends: Pin clang search paths for darwin host #19683
Conversation
Concept ACK - did not read the @ajtowns poem. Did you want to link to your other recent gist here as well? |
Added to description! It's also in the comments added to |
Gitian builds
|
abc1325
to
79f4693
Compare
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. |
e1264c6
to
0656f1f
Compare
Updated so that it no longer depends on #20019. |
|
0656f1f
to
24b43da
Compare
9ac6a28
to
ce2332f
Compare
Currently figuring out how to make |
a3c1505
to
549e2ae
Compare
Many thanks to ajtowns for the above contribution!
This PR is ready for review!
When cross-compiling for macOS, the SDK gives us the entire context/sysroot on which we should base the build. This means that we can be extremely specific w/re our search path ordering in order to avoid build problems that arise out of a user's specific environment/system setup and improve the robustness of our macOS toolchain. This PR does 2 things to this end:
Unset environment variables which are known to alter search paths.
Makes us (in the case of macOS builds) explicitly specify the list of system include search paths and its ordering, rather than rely on
clang
's unreliable autodetection routine. Here is the rabbit-hole gist.See the added comments in
depends/hosts/darwin.mk
for more details:bitcoin/depends/hosts/darwin.mk
Lines 37 to 60 in 8b8296d
We can be this specific only because macOS builds are neatly contained in an SDK, and we are cross-compiling. Native toolchains should rely on the environment/distro/user to know how best to build for the running system.
Note: Although the
-u
flag ofenv
is not a POSIX standard flag, it seems like it is useful enough to be implemented in coreutils, busybox, FreeBSD.