Use /usr/bin/strip on macOS -> iOS cross as a temporary workaround

[jieyouxu]

Backup crude workaround for #138212 to unblock nightly macOS-to-iOS cross builds. This reintroduces the "hard-coded strip" workaround (but only for iOS) that was initially introduced in #130781.

Looks like LLVM 20's initial llvm-objcopy version that we ship as rust-objcopy may be producing stripped iOS binaries with invalid offsets that fail iOS platform consistency checks.

For the time being, use macOS system strip when cross-compiling from macOS -> iOS at /usr/bin/strip which should be available (unlike Linux -> macOS cross where this is not guaranteed to be available, partially why we are shipping llvm-objcopy in the first place¹) that shouldn't have this offset problem.

Preferrably it should be addressed by syncing back the upstream llvm-objcopy fix, but this is opened in case the upstream fix takes some time to merge and be synced back.

Alternatives

• We could also try to use a strip from PATH. However, that can regress iOS users if they have broken homebrew binutils strip in their PATH that take precedence over a "good" strip.
• We could also wait for upstream llvm-objcopy fixes in [llvm-objcopy] Apply encryptable offset to first segment, not section llvm/llvm-project#130517.

Review and testing advice

I don't have access to either macOS or iOS platforms, and I can't really write a test for this. This will need to be tested manually.

r? @davidtwco (or reroll)
cc *-apple-ios target maintainers @badboy @deg4uss3r @madsmtm

try-job: dist-apple-various
try-job: dist-x86_64-apple
try-job: dist-aarch64-apple

Footnotes

1. https://github.com/rust-lang/rust/issues/131206 ↩

[jieyouxu]

@bors try

[bors]

⌛ Trying commit 908c5e4 with merge 06d1077...

[bors]

☀️ Try build successful - checks-actions
Build commit: 06d1077 (06d1077d5ba6da9a0b3b6b84e6f919ec600dc1b6)

[madsmtm]

Fine with this workaround (depending on how long llvm/llvm-project#130472 takes).

[TimNN]

I can't really write a test for this. This will need to be tested manually.

Does CI run "macOS host, iOS target" run-make tests on CI? If so, we could check that dyld_info correctly parses the produced output files.

(Though I don't know if we actually want such a test, ideally we should be able to rely on strip / llvm-objcopy doing the right thing).

[jieyouxu]

Does CI run "macOS host, iOS target" run-make tests on CI? If so, we could check that dyld_info correctly parses the produced output files.

(Though I don't know if we actually want such a test, ideally we should be able to rely on strip / llvm-objcopy doing the right thing).

I think we do run run-make tests on macOS-to-iOS, but I think we probably don't want to maintain our own strip test.

[jieyouxu]

This probably still needs someone with access to the native envs to try an end-to-end test to see if the resulting rustc can produce an iOS binary that doesn't immediately crash.

@rustbot ready

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[jieyouxu]

@bors try

[bors]

⌛ Trying commit d88636f with merge d1f7fb3...

[bors]

☀️ Try build successful - checks-actions
Build commit: d1f7fb3 (d1f7fb3751190d6b1c8642ea402d066147d01e28)

[badboy]

This probably still needs someone with access to the native envs to try an end-to-end test to see if the resulting rustc can produce an iOS binary that doesn't immediately crash.

@rustbot ready

I'm back at work tomorrow and can probably take some time and get me a Rust build to try this.

[badboy]

I did build rustc with this patch. And dyld_info does now report things about compiled libraries for that target.
Unfortunately I have not been able to actually deploy that on an actual iOS device (between Xcode, my test phone and codesigning things just ... break). Our own app uses a static lib, so that wasn't affected to begin with.

[jieyouxu]

No worries, thanks for trying anyway :D

[jieyouxu]

Closing in favor of proper upstream fix #138695