You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even the newest macos sdks all have support for much older "deployment targets" (you can tell the 14 sdk to build for 10.12, for instance). This is governed by MACOSX_DEPLOYMENT_TARGET env var. At best, cargo-dist should default to automatically setting this to a reasonable value. At worst we should have docs telling people to set this in their cargo-dist env-vars (and we should test it works! i have a macos 11 intel macbook to test with).
Doing this would unblock us unabashedly using the apple silicon runners, which would be a huge win.
Even the newest macos sdks all have support for much older "deployment targets" (you can tell the 14 sdk to build for 10.12, for instance). This is governed by MACOSX_DEPLOYMENT_TARGET env var. At best, cargo-dist should default to automatically setting this to a reasonable value. At worst we should have docs telling people to set this in their cargo-dist env-vars (and we should test it works! i have a macos 11 intel macbook to test with).
Doing this would unblock us unabashedly using the apple silicon runners, which would be a huge win.
A former apple compiler engineer who now does a lot of rust dev has informed me that this env-var has a ton of confusing discussion, and that the value rustc "defaults" to is just for the stdlib/itself, seemingly rust binaries you build default to deployment_target == sdk_version which is of course a portability nightmare.
For reference, rustc defaults to 10.12 for itself (
rustc --target x86_64-apple-darwin --print deployment-target
), which is super generous.See also this (confusing) issue about how cargo doesn't set the env-var for build scripts, which makes cdeps very sad: rust-lang/cargo#13115
The text was updated successfully, but these errors were encountered: