Add support for link-flavor rust-lld for macOS #100286
Merged
Conversation
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
rustbot
added
the
T-compiler
|
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
|
rust-highfive
added
the
S-waiting-on-review
petrochenkov
reviewed
Aug 8, 2022
petrochenkov
added
S-waiting-on-author
Also refactor iOS, watchOS and tvOS common code.
marysaka
force-pushed
the
rust-lld-macosx-target
branch
from
f556102 to
a725250
Compare
|
@rustbot label -S-waiting-on-author +S-waiting-on-review |
rustbot
added
S-waiting-on-review
|
@bors r+ |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 10, 2022
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#100286 (Add support for link-flavor rust-lld for macOS) - rust-lang#100317 (Remove logic related to deprecated nvptx-nvidia-cuda (32-bit) target) - rust-lang#100339 (Fixes bootstrap panic when running x fmt --check ) - rust-lang#100348 (Add regression test for rust-lang#93205) - rust-lang#100349 (Refactor: remove a type string comparison) - rust-lang#100353 (Fix doc links in core::time::Duration::as_secs) - rust-lang#100359 (Special-case references to leafs in valtree pretty-printing) - rust-lang#100371 (Inline CStr::from_bytes_with_nul_unchecked::rt_impl) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 14, 2024
…eyouxu Fix `SDKROOT` ignore on macOS `rustc` has code to detect when `SDKROOT` is obviously set for the wrong platform, so that it can choose to ignore it. This is a pretty important feature for Cargo build scripts and proc macros, since you will often have `SDKROOT` set to an iOS platform there. However, the code was checking for an old SDK version name `"macosx10.15"` that was previously configured by `add_apple_sdk`, but nowadays configured to the correct `"macosx"`. I think this error was introduced in part rust-lang#77202 and in rust-lang#100286. Fixes part of rust-lang#80817 (linking with `-Clinker=ld` now works), though more work is still needed in this area, see also rust-lang#129432. `@rustbot` label O-macos A-cross
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 14, 2024
…eyouxu Fix `SDKROOT` ignore on macOS `rustc` has code to detect when `SDKROOT` is obviously set for the wrong platform, so that it can choose to ignore it. This is a pretty important feature for Cargo build scripts and proc macros, since you will often have `SDKROOT` set to an iOS platform there. However, the code was checking for an old SDK version name `"macosx10.15"` that was previously configured by `add_apple_sdk`, but nowadays configured to the correct `"macosx"`. I think this error was introduced in part rust-lang#77202 and in rust-lang#100286. Fixes part of rust-lang#80817 (linking with `-Clinker=ld` now works), though more work is still needed in this area, see also rust-lang#129432. ``@rustbot`` label O-macos A-cross
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 14, 2024
Rollup merge of rust-lang#130334 - madsmtm:macos-sdkroot-ignore, r=jieyouxu Fix `SDKROOT` ignore on macOS `rustc` has code to detect when `SDKROOT` is obviously set for the wrong platform, so that it can choose to ignore it. This is a pretty important feature for Cargo build scripts and proc macros, since you will often have `SDKROOT` set to an iOS platform there. However, the code was checking for an old SDK version name `"macosx10.15"` that was previously configured by `add_apple_sdk`, but nowadays configured to the correct `"macosx"`. I think this error was introduced in part rust-lang#77202 and in rust-lang#100286. Fixes part of rust-lang#80817 (linking with `-Clinker=ld` now works), though more work is still needed in this area, see also rust-lang#129432. ``@rustbot`` label O-macos A-cross
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 9, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it.
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
12 tasks
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Oct 31, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Nov 3, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Nov 3, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Nov 3, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Nov 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Nov 10, 2024
The exact reasoning why we do not always pass the SDK root with `-isysroot` to `cc` when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support `cc`s which do not support this option. So instead, we pass the SDK root via the environment variable SDKROOT. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK root in some other way) can just ignore it. This fixes rust-lang#80817 (by always passing the SDK root, even when linking with cc on macOS).
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Aug 11, 2025
The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. Since we now pass the SDK root via the environment variable SDKROOT, compiler drivers that don't support it can just ignore it. Similarly, since we only warn when xcrun fails, users that expect their compiler driver to provide the SDK location can do so now.
madsmtm
added a commit
to madsmtm/rust
that referenced
this pull request
Aug 11, 2025
The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. Since we now pass the SDK root via the environment variable SDKROOT, compiler drivers that don't support it can just ignore it. Similarly, since we only warn when xcrun fails, users that expect their compiler driver to provide the SDK location can do so now.
fmease
added a commit
to fmease/rust
that referenced
this pull request
Aug 11, 2025
…thercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes rust-lang#80817, fixes rust-lang#96943, and generally simplifies our linker invocation on Apple platforms. Part of rust-lang#129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see rust-lang#80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC `@BlackHoleFox` `@thomcc`
fmease
added a commit
to fmease/rust
that referenced
this pull request
Aug 12, 2025
…thercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes rust-lang#80817, fixes rust-lang#96943, and generally simplifies our linker invocation on Apple platforms. Part of rust-lang#129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see rust-lang#80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC ``@BlackHoleFox`` ``@thomcc``
fmease
added a commit
to fmease/rust
that referenced
this pull request
Aug 12, 2025
…thercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes rust-lang#80817, fixes rust-lang#96943, and generally simplifies our linker invocation on Apple platforms. Part of rust-lang#129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see rust-lang#80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC ```@BlackHoleFox``` ```@thomcc```
fmease
added a commit
to fmease/rust
that referenced
this pull request
Aug 12, 2025
…thercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes rust-lang#80817, fixes rust-lang#96943, and generally simplifies our linker invocation on Apple platforms. Part of rust-lang#129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see rust-lang#80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC ````@BlackHoleFox```` ````@thomcc````
fmease
added a commit
to fmease/rust
that referenced
this pull request
Aug 12, 2025
…thercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes rust-lang#80817, fixes rust-lang#96943, and generally simplifies our linker invocation on Apple platforms. Part of rust-lang#129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see rust-lang#80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC `````@BlackHoleFox````` `````@thomcc`````
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 12, 2025
…thercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes rust-lang#80817, fixes rust-lang#96943, and generally simplifies our linker invocation on Apple platforms. Part of rust-lang#129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see rust-lang#80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC ``````@BlackHoleFox`````` ``````@thomcc``````
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Aug 12, 2025
…thercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes rust-lang#80817, fixes rust-lang#96943, and generally simplifies our linker invocation on Apple platforms. Part of rust-lang#129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see rust-lang#80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC ```````@BlackHoleFox``````` ```````@thomcc```````
rust-timer
added a commit
that referenced
this pull request
Aug 12, 2025
Rollup merge of #131477 - madsmtm:sdkroot-via-env-var, r=nnethercote Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var Fixes #80817, fixes #96943, and generally simplifies our linker invocation on Apple platforms. Part of #129432. ### Necessary background on trampoline binaries The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`. This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly): - `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk` - `LIBRARY_PATH=/usr/local/lib` (appended) - `CPATH=/usr/local/include` (appended) - `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended) This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools. (It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`). ### Finding a suitable SDK All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above). But relying on the `cc` trampoline doesn't work when: - Cross-compiling, since a different SDK is needed there. - Invoking the linker directly, since the linker doesn't understand `SDKROOT`. - Linking build scripts inside Xcode (see #80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified. Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**. Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below. #### No Xcode There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`. We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit. #### `SDKROOT` vs. `-isysroot` The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in #100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option. To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it. One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any? In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool. Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`). ### Considered alternatives - Invoke `/usr/bin/cc` instead of `cc`. - This breaks many other use-cases though where overriding `cc` in the PATH is desired. - Look up `which cc`, and do special logic if in Xcode toolchain. - Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical. - Invoke `xcrun --sdk macosx cc`. - This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable. - Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible. - Bundle the SDK, similar to `zig-cc`. - Comes with it's own host of problems. ### Testing Tested that this works with the following `-Clinker=...`: - [x] Default (`cc`) - [x] `/usr/bin/ld` - [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`) - [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`) - [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK) - [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK) - [x] ~Macports `clang`~ Couldn't get it to build - [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK) - [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK) - [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK) - [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK) - [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`) CC ```````@BlackHoleFox``````` ```````@thomcc```````
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.
Also refactor iOS, watchOS and tvOS common code.
The
-archargument was moved to theapple_basemodule instead of the target definitions for macOS.As ld64 requires
-syslibrootto be passed,add_apple_sdkwas modified accordingly.