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

Add support for link-flavor rust-lld for macOS #100286

Merged
merged 1 commit into from
Aug 10, 2022
Merged

Add support for link-flavor rust-lld for macOS #100286

merged 1 commit into from
Aug 10, 2022

Conversation

marysaka
Copy link
Contributor

@marysaka marysaka commented Aug 8, 2022

Also refactor iOS, watchOS and tvOS common code.

The -arch argument was moved to the apple_base module instead of the target definitions for macOS.
As ld64 requires -syslibroot to be passed, add_apple_sdk was modified accordingly.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Aug 8, 2022
@rust-highfive
Copy link
Collaborator

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 8, 2022
@petrochenkov
Copy link
Contributor

r? @petrochenkov

petrochenkov
petrochenkov reviewed Aug 8, 2022
View reviewed changes
compiler/rustc_target/src/spec/apple_base.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/spec/apple_base.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/spec/apple_base.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/spec/i686_apple_darwin.rs Outdated Show resolved Hide resolved
@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 8, 2022
@marysaka
Add support for link-flavor rust-lld for macOS
a725250 
Also refactor iOS, watchOS and tvOS common code.
@marysaka
Copy link
Contributor Author

marysaka commented Aug 9, 2022

@rustbot label -S-waiting-on-author +S-waiting-on-review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 9, 2022
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Aug 9, 2022

📌 Commit a725250 has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 9, 2022
@compiler-errors compiler-errors mentioned this pull request Aug 10, 2022
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 10, 2022
@bors
Auto merge of rust-lang#100378 - compiler-errors:rollup-8vzsd92, r=co…
7bc32fa 
…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
@bors bors merged commit d0d2f60 into rust-lang:master Aug 10, 2022
@rustbot rustbot added this to the 1.65.0 milestone Aug 10, 2022
@madsmtm madsmtm mentioned this pull request Sep 14, 2024
Merged
Zalathar added a commit to Zalathar/rust that referenced this pull request 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 pull request 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 pull request 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 pull request Oct 9, 2024
@madsmtm
Always attempt to get SDK root, and pass it to Clang via env var
339ca4f 
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
@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 pull request 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 mentioned this pull request Oct 10, 2024
Open
madsmtm added a commit to madsmtm/rust that referenced this pull request 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 pull request 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 pull request 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 pull request 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 pull request 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
Reviewers

@petrochenkov petrochenkov petrochenkov left review comments

Assignees

@petrochenkov petrochenkov

Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.65.0
Development

Successfully merging this pull request may close these issues.
6 participants
@marysaka @rust-highfive @petrochenkov @bors @estebank @rustbot