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

Deployment target incorrect in rust-std assets on apple platforms #1171

Open
Reflejo opened this issue Aug 4, 2024 · 2 comments
Open

Deployment target incorrect in rust-std assets on apple platforms #1171

Reflejo opened this issue Aug 4, 2024 · 2 comments

Comments

@Reflejo
Copy link

Reflejo commented Aug 4, 2024

After this PR, the rust-std assets built in CI (nightly/beta/stable/etc) have an incorrect deployment target on darwin. rust-std was relying on. rusts' default targets when IPHONEOS_DEPLOYMENT_TARGET was not set and the CI job does not include that env var.

Meaning that when rust-std is built with the c feature (it is for all assets), the rust-std rlib takes the maximum minos which thanks to libcompile-rt is now the host sdk-version.

Related issue rust-lang/compiler-builtins#650 (comment)

I proposed two solutions in the previous issue, let me know if you think of a third.

cc @BlackHoleFox

@BlackHoleFox
Copy link
Contributor

From your options I think its better if Rust's CI sets the environment variable to control it. imo compiler-builtins should use the same variables as std, or maybe it would be enough if Rust's CI set IPHONEOS_DEPLOYMENT_TARGET next to the macOS one (seems like a bug that its not there as well).

I do sympathize and apologize for the upstream bug :( I don't think this is for cc to fix, see below for a longer explanation why. I'll ping @NobodyXu in case though.

Long-winded tangent time, though: We have significantly struggled to find the "right default" for everyone now that Rust's deployment target can be different then 7.0 from years ago. We nuked the rustc querying from cc because it broke too many people's build setups where they were relying on the XCode-ish behavior of your current SDK, when they actually should have been setting the variable (like Apple intends, but Rust projects historically haven't cared about this for above reasons). A perfect world would let us restore the rustc querying default (so Rust projects stick with Rust's defaults, instead of Apple's) and tell everyone to set their deployment targets like every XCode and SwiftPM project have you do. Alas though!

@madsmtm
Copy link
Contributor

madsmtm commented Sep 29, 2024

Long-winded tangent time, though: We have significantly struggled to find the "right default" for everyone now that Rust's deployment target can be different then 7.0 from years ago. We nuked the rustc querying from cc because it broke too many people's build setups where they were relying on the XCode-ish behavior of your current SDK, when they actually should have been setting the variable (like Apple intends, but Rust projects historically haven't cared about this for above reasons). A perfect world would let us restore the rustc querying default (so Rust projects stick with Rust's defaults, instead of Apple's) and tell everyone to set their deployment targets like every XCode and SwiftPM project have you do. Alas though!

Actually, do you think it would be viable to revisit that now that the default deployment target is 10.12? From what I can tell from #900, it seems like it broke a lot of builds back then when set to macOS 10.7, which was lower than the 10.9 that was require to link certain C++ libraries, but did you encounter other problems?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@Reflejo @madsmtm @BlackHoleFox and others