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.

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

Link with default MACOSX_DEPLOYMENT_TARGET if not otherwise specified. #90499

Merged
merged 3 commits into from
Nov 25, 2021

Conversation

hkratz
Copy link
Contributor

@hkratz hkratz commented Nov 2, 2021

This PR sets the MACOSX_DEPLOYMENT_TARGET environment variable during the linking stage to our default, if it is not specified. This way it matches the deployment target we pass to llvm. If not set the the linker uses Xcode or Xcode commandline tools default which varies by version.

Fixes #90342, #91082.

Drive-by fixes to make Rust behave more like clang:

  • Default to 11.0 deployment target for ARM64 which is the earliest version that had support for it.
  • Set the llvm target to arm64-apple-macosx<deployment target> instead of aarch64-apple-macosx<deployment target>.

@rust-highfive
Copy link
Collaborator

r? @jackh726

(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 Nov 2, 2021
@crlf0710 crlf0710 added the O-macos Operating system: macOS label Nov 2, 2021
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 11, 2021
@camelid camelid linked an issue Nov 20, 2021 that may be closed by this pull request
@jackh726
Copy link
Member

Not at all familiar here, rerolling.

r? rust-lang/compiler

@petrochenkov
Copy link
Contributor

r=me with the nit addressed.

@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 Nov 25, 2021
@hkratz
Copy link
Contributor Author

hkratz commented Nov 25, 2021

Nit fixed (squashed into the commit).

@rustbot ready

@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 Nov 25, 2021
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Nov 25, 2021

📌 Commit b376f56 has been approved by petrochenkov

@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 Nov 25, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 25, 2021
…askrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#89359 (Various fixes for const_trait_impl)
 - rust-lang#90499 (Link with default MACOSX_DEPLOYMENT_TARGET if not otherwise specified.)
 - rust-lang#91096 (Print associated types on opaque `impl Trait` types)
 - rust-lang#91111 (Do not visit attributes in `ItemLowerer`.)
 - rust-lang#91162 (explain why CTFE/Miri perform truncation on shift offset)
 - rust-lang#91185 (Remove `-Z force-overflow-checks`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 0780889 into rust-lang:master Nov 25, 2021
@rustbot rustbot added this to the 1.58.0 milestone Nov 25, 2021
@hkratz hkratz deleted the macos-target-fixes branch November 25, 2021 19:54
@madsmtm
Copy link
Contributor

madsmtm commented Nov 29, 2021

Isn't this applicable for IPHONEOS_DEPLOYMENT_TARGET on iOS as well?

hkratz added a commit to rusticstuff/rust that referenced this pull request Dec 13, 2021
…f not set."

This reverts commit b376f56, which is
the main part of rust-lang#90499, because it turns out that this causes a good
amount of breakage in crates relying on the old behavior.

Fixes rust-lang#91372.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 14, 2021
…rt, r=Mark-Simulacrum

Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking

This reverts commit b376f56, which is the main part of rust-lang#90499, because it turns out that this causes a good amount of breakage in crates relying on the old behavior. In particular `winit`, `coreaudio` and crates that depend on them are affected. Fixes rust-lang#91372.

Background:
Before rust-lang#90499 the behavior was the following: If MACOSX_DEPLOYMENT_TARGET is not set,  we pass the minimum supported OS version to LLVM but not to the linker. The linker default depends on the Xcode version and the version of the OS it is running on. That caused one known problem in libcurl with the most recent Xcode versions. rust-lang#90499 passed the minumum supported version (10.7 for Macos x86-64) to the linker instead. This has shown to be problematic because some crates such as winit, coreaudio implicitly expect a newer minimum OS version. The libcurl issue has been fixed independently (see alexcrichton/curl-rust#417), so a revert should not really be problematic.

Eventually we should probably mimic clang's behavior and fall back to the default of the currently configured Macos SDK for both the LLVM min os target version and MACOSX_DEPLOYMENT_TARGET for linking. That would entail looking at the `Version` property of the `SDKSettings.json` in the currently configured SDK.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 14, 2021
…rt, r=Mark-Simulacrum

Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking

This reverts commit b376f56, which is the main part of rust-lang#90499, because it turns out that this causes a good amount of breakage in crates relying on the old behavior. In particular `winit`, `coreaudio` and crates that depend on them are affected. Fixes rust-lang#91372.

Background:
Before rust-lang#90499 the behavior was the following: If MACOSX_DEPLOYMENT_TARGET is not set,  we pass the minimum supported OS version to LLVM but not to the linker. The linker default depends on the Xcode version and the version of the OS it is running on. That caused one known problem in libcurl with the most recent Xcode versions. rust-lang#90499 passed the minumum supported version (10.7 for Macos x86-64) to the linker instead. This has shown to be problematic because some crates such as winit, coreaudio implicitly expect a newer minimum OS version. The libcurl issue has been fixed independently (see alexcrichton/curl-rust#417), so a revert should not really be problematic.

Eventually we should probably mimic clang's behavior and fall back to the default of the currently configured Macos SDK for both the LLVM min os target version and MACOSX_DEPLOYMENT_TARGET for linking. That would entail looking at the `Version` property of the `SDKSettings.json` in the currently configured SDK.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 14, 2021
…rt, r=Mark-Simulacrum

Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking

This reverts commit b376f56, which is the main part of rust-lang#90499, because it turns out that this causes a good amount of breakage in crates relying on the old behavior. In particular `winit`, `coreaudio` and crates that depend on them are affected. Fixes rust-lang#91372.

Background:
Before rust-lang#90499 the behavior was the following: If MACOSX_DEPLOYMENT_TARGET is not set,  we pass the minimum supported OS version to LLVM but not to the linker. The linker default depends on the Xcode version and the version of the OS it is running on. That caused one known problem in libcurl with the most recent Xcode versions. rust-lang#90499 passed the minumum supported version (10.7 for Macos x86-64) to the linker instead. This has shown to be problematic because some crates such as winit, coreaudio implicitly expect a newer minimum OS version. The libcurl issue has been fixed independently (see alexcrichton/curl-rust#417), so a revert should not really be problematic.

Eventually we should probably mimic clang's behavior and fall back to the default of the currently configured Macos SDK for both the LLVM min os target version and MACOSX_DEPLOYMENT_TARGET for linking. That would entail looking at the `Version` property of the `SDKSettings.json` in the currently configured SDK.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 15, 2021
…rt, r=Mark-Simulacrum

Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking

This reverts commit b376f56, which is the main part of rust-lang#90499, because it turns out that this causes a good amount of breakage in crates relying on the old behavior. In particular `winit`, `coreaudio` and crates that depend on them are affected. Fixes rust-lang#91372.

Background:
Before rust-lang#90499 the behavior was the following: If MACOSX_DEPLOYMENT_TARGET is not set,  we pass the minimum supported OS version to LLVM but not to the linker. The linker default depends on the Xcode version and the version of the OS it is running on. That caused one known problem in libcurl with the most recent Xcode versions. rust-lang#90499 passed the minumum supported version (10.7 for Macos x86-64) to the linker instead. This has shown to be problematic because some crates such as winit, coreaudio implicitly expect a newer minimum OS version. The libcurl issue has been fixed independently (see alexcrichton/curl-rust#417), so a revert should not really be problematic.

Eventually we should probably mimic clang's behavior and fall back to the default of the currently configured Macos SDK for both the LLVM min os target version and MACOSX_DEPLOYMENT_TARGET for linking. That would entail looking at the `Version` property of the `SDKSettings.json` in the currently configured SDK.
Mark-Simulacrum pushed a commit to Mark-Simulacrum/rust that referenced this pull request Jan 5, 2022
…f not set."

This reverts commit b376f56, which is
the main part of rust-lang#90499, because it turns out that this causes a good
amount of breakage in crates relying on the old behavior.

Fixes rust-lang#91372.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-macos Operating system: macOS 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
10 participants