Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Linker errors when cross-compiling from Xcode on Big Sur #80817

Open
irh opened this issue Jan 8, 2021 · 2 comments · May be fixed by #131477
Open

Linker errors when cross-compiling from Xcode on Big Sur #80817

irh opened this issue Jan 8, 2021 · 2 comments · May be fixed by #131477
Labels
A-cross Area: Cross compilation C-bug Category: This is a bug. O-macos Operating system: macOS

Comments

@irh
Copy link

irh commented Jan 8, 2021

Hi all, invoking cargo build from Xcode on Big Sur currently fails when a crate needs to link against a system library from a build script, unless SDKROOT has been explicitly set to the path of the macOS SDK. Test project here.

When invoking cargo build from an Xcode build script, SDKROOT is set for the platform that's being built. #64254 made it so that SDKROOT gets un-set if the target platform doesn't match the host platform. This seems reasonable to me, but then I don't understand why there's now a difference in behaviour between Xcode and non-Xcode builds.

I logged a similiar issue for cargo-lipo, which has a different workaround of instead setting LIBRARY_PATH.
@irh irh added the C-bug Category: This is a bug. label Jan 8, 2021
@camelid camelid added A-cross Area: Cross compilation O-macos Operating system: macOS labels Jan 11, 2021
@nfriedly
Copy link

nfriedly commented Dec 14, 2022 •
edited
Loading

My team has also been hitting this issue since macOS 11/Big Sur, and initially setting the LIBRARY_PATH and SDK_ROOT seemed to make it work, but after upgrading to macOS 14/Ventura, I (and apparently only I) started hitting this same issue again. I dug into it for a while and noticed this tidbit mentioning that Xcode's copy of ld behaves differently from the one in /usr/bin.

So, the final solution I settled on was undoing my LIBRARY_PATH and SDK_ROOT and instead resetting PATH to exclude all of the Xcode folders in my build script:

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"

After that, rust builds seem to work reliably from both Xcode and the command line.

@madsmtm madsmtm mentioned this issue Aug 21, 2024
Open
@madsmtm madsmtm mentioned this issue Sep 14, 2024
Merged
Zalathar added a commit to Zalathar/rust that referenced this issue Sep 14, 2024
@Zalathar
Rollup merge of rust-lang#130334 - madsmtm:macos-sdkroot-ignore, r=ji…
55d5c32 
…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 issue Sep 14, 2024
@Zalathar
Rollup merge of rust-lang#130334 - madsmtm:macos-sdkroot-ignore, r=ji…
73f684f 
…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 issue Sep 14, 2024
@rust-timer
Unrolled build for rust-lang#130334
fc6087b 
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 issue Oct 10, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
e6479fc 
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 issue Oct 10, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
6aaa795 
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 madsmtm linked a pull request Oct 10, 2024 that will close this issue
Open
@madsmtm
Copy link
Contributor

madsmtm commented Oct 10, 2024 •
edited
Loading

I can reproduce this with:

PATH="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:$PATH" rustc foo.rs

With the current nightly, it should work with -Clinker-flavor=ld, and #131477 will make this work with the default linker.

madsmtm added a commit to madsmtm/rust that referenced this issue Oct 10, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
6d94e37 
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 issue Oct 10, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
97e382d 
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 issue Oct 10, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
eeea5f0 
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 issue Oct 10, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
8ca8d4f 
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 issue Oct 10, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
25e7f0f 
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-cross Area: Cross compilation C-bug Category: This is a bug. O-macos Operating system: macOS
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

macOS: Always pass SDK root when linking with cc, and pass it via SDKROOT env var madsmtm/rust
4 participants
@nfriedly @irh @madsmtm @camelid