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

Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking #91870

Merged
merged 1 commit into from Dec 15, 2021

Conversation

hkratz
Copy link
Contributor

@hkratz hkratz commented Dec 13, 2021

This reverts commit b376f56, which is the main part of #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 #91372.

Background:
Before #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. #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.

…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.
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 13, 2021
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(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 Dec 13, 2021
@Mark-Simulacrum Mark-Simulacrum added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Dec 13, 2021
@hkratz
Copy link
Contributor Author

hkratz commented Dec 14, 2021

Added some more background to the issue description to make it easier to review.

@Mark-Simulacrum
Copy link
Member

@bors r+

Going to go ahead and approve this, as I think the rationale for a revert for now makes sense.

@bors
Copy link
Contributor

bors commented Dec 14, 2021

📌 Commit 3011154 has been approved by Mark-Simulacrum

@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 Dec 14, 2021
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.
This was referenced Dec 14, 2021
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.
This was referenced Dec 14, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 15, 2021
…askrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#90939 (Tweak errors coming from `for`-loop, `?` and `.await` desugaring)
 - rust-lang#91859 (Iterator::cycle() — document empty iterator special case)
 - rust-lang#91868 (Use `OutputFilenames` to generate output file for `-Zllvm-time-trace`)
 - rust-lang#91870 (Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking)
 - rust-lang#91881 (Stabilize `iter::zip`)
 - rust-lang#91882 (Remove `in_band_lifetimes` from `rustc_typeck`)
 - rust-lang#91940 (Update cargo)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 2f270e4 into rust-lang:master Dec 15, 2021
@rustbot rustbot added this to the 1.59.0 milestone Dec 15, 2021
@pnkfelix
Copy link
Member

discussed in T-compiler triage meeting. beta-accepted.

@pnkfelix pnkfelix added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Dec 16, 2021
@Mark-Simulacrum Mark-Simulacrum removed this from the 1.59.0 milestone Jan 5, 2022
@Mark-Simulacrum Mark-Simulacrum added this to the 1.58.0 milestone Jan 5, 2022
@Mark-Simulacrum Mark-Simulacrum removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jan 5, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 8, 2022
…ulacrum

[beta] backports

Backports these PRs:

* Fix HashStable implementation on InferTy rust-lang#91892
* Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking rust-lang#91870
* Make rustdoc headings black, and markdown blue rust-lang#91534
* Disable LLVM newPM by default rust-lang#91190
* Deduplicate projection sub-obligations rust-lang#90423
*  Sync portable-simd to remove autosplats rust-lang#91484 by dropping portable_simd entirely (keeping the subtree, just from std/core)
*  Quote bat script command line rust-lang#92208
* Fix failing tests rust-lang#92201 (CI fix)

r? `@Mark-Simulacrum`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. 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
Development

Successfully merging this pull request may close these issues.

Linking to private symbols from frameworks between compilation units
7 participants