-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Always add LC_BUILD_VERSION for metadata object files #114114
Always add LC_BUILD_VERSION for metadata object files #114114
Conversation
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
These commits modify compiler targets. |
I won't have time to review this before a week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes seem fine to me but I don't have much knowledge of Apple platforms. @thomcc I think you might have more context here. Does this seem ok to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not the reviewer here, or @thomcc, but I do have some questions/suggestions as someone who has worked in these files a lot.
@@ -274,6 +320,11 @@ fn ios_deployment_target() -> (u32, u32) { | |||
from_set_deployment_target("IPHONEOS_DEPLOYMENT_TARGET").unwrap_or((7, 0)) | |||
} | |||
|
|||
fn mac_catalyst_deployment_target() -> (u32, u32) { | |||
// If you are looking for the default deployment target, prefer `rustc --print deployment-target`. | |||
from_set_deployment_target("IPHONEOS_DEPLOYMENT_TARGET").unwrap_or((14, 0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did 14.0 come from here? Was it just because that's the current assumed target in the other spec files?
IMO (not the reviewer here) its fine to do this but in some followup the hardcoded versions in the current catalyst target specs should get nuked. This would match what users would expect now that were reading this variable. Definitely doesn't need to be done here though I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pulled it from the original implementation of this behavior that only applied to catalyst https://github.com/rust-lang/rust/pull/114114/files#diff-6bbf6edd930f26d3b180eb5c250b0e48d8f3c5eb474e3274909ef6ae6f0d1e61L343
I agree having it configurable makes sense, at least in this case if you set IPHONEOS_DEPLOYMENT_TARGET
it would win though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed the lines removed in the diff, oops. That answers the immediate question then.
I agree having it configurable makes sense, at least in this case if you set IPHONEOS_DEPLOYMENT_TARGET it would win though
Do you want to take that to a followup PR or shall I? Fixing the mess that's Catalyst has been on my list forever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can send that one after!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah it looks like using the triple for this case 78bbe57#diff-f2aa7189f140501f7d0d283ef503e1980a9449ef0292b48b650f6e0c87bb8d6b complicates things slightly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iiuc it should just be making another of the <target_here>_lld_platform_version
functions to use for this and other LLVM needs and have that source from the deployment target function. Might have missed a complication with the catalyst target though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sounds good I can try it after this one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like to make this work I would need to change add_pre_link_args
to take a String
or something else since ours would be dynamically computed here, would that be a reasonable change?
I missed this ping until now, but my opinion would be to defer to @BlackHoleFox's review, which seems quite thorough and accurate. |
As of Xcode 15 Apple's linker has become a bit more strict about the warnings it produces. One of those new warnings requires all valid Mach-O object files in an archive to have a LC_BUILD_VERSION load command: ``` ld: warning: no platform load command found in 'ARCHIVE[arm64][2106](lib.rmeta)', assuming: iOS-simulator ``` This was already being done for Mac Catalyst so this change expands this logic to include it for all Apple platforms. I filed this behavior change as FB12546320 and was told it was the new intentional behavior.
8dceddb
to
d37fdc9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wesleywiser this looks good to r+ from me now.
@bors r+ rollup=never (in case we need to bisect to this PR later) |
☀️ Test successful - checks-actions |
thanks all! |
Finished benchmarking commit (84a9f4c): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 630.72s -> 630.625s (-0.02%) |
…r=jieyouxu Apple: Do not specify an SDK version in `rlib` object files This was added in rust-lang#114114, but is unnecessary, since it ends up being overwritten when linking anyhow, and it feels wrong to embed some arbitrary SDK version in here. The object files produced by LLVM also do not set this, and the tooling shows `n/a` when it's `0`, so it seems to genuinely be optional in object files. I've also added a test for the different places the SDK version shows up, and documented a bit more in the code how SDK versions work. See rust-lang#129432 for the bigger picture. Tested with (excludes the same few targets as in rust-lang#130435): ```console ./x test tests/run-make/apple-sdk-version --target aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7k-apple-watchos,armv7s-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin IPHONEOS_DEPLOYMENT_TARGET=10.0 ./x test tests/run-make/apple-sdk-version --target=i386-apple-ios ``` CC `@BlackHoleFox,` you [originally commented on these values](rust-lang#114114 (comment)). `@rustbot` label O-apple
Rollup merge of rust-lang#131016 - madsmtm:no-sdk-version-in-object, r=jieyouxu Apple: Do not specify an SDK version in `rlib` object files This was added in rust-lang#114114, but is unnecessary, since it ends up being overwritten when linking anyhow, and it feels wrong to embed some arbitrary SDK version in here. The object files produced by LLVM also do not set this, and the tooling shows `n/a` when it's `0`, so it seems to genuinely be optional in object files. I've also added a test for the different places the SDK version shows up, and documented a bit more in the code how SDK versions work. See rust-lang#129432 for the bigger picture. Tested with (excludes the same few targets as in rust-lang#130435): ```console ./x test tests/run-make/apple-sdk-version --target aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7k-apple-watchos,armv7s-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin IPHONEOS_DEPLOYMENT_TARGET=10.0 ./x test tests/run-make/apple-sdk-version --target=i386-apple-ios ``` CC `@BlackHoleFox,` you [originally commented on these values](rust-lang#114114 (comment)). `@rustbot` label O-apple
As of Xcode 15 Apple's linker has become a bit more strict about the warnings it produces. One of those new warnings requires all valid Mach-O object files in an archive to have a LC_BUILD_VERSION load command:
This was already being done for Mac Catalyst so this change expands this logic to include it for all Apple platforms. I filed this behavior change as FB12546320 and was told it was the new intentional behavior.