Open Augustyniak opened 4 months ago
@madsmtm do you know if something happened with our iOS versions? https://doc.rust-lang.org/nightly/rustc/platform-support/apple-ios.html still lists 10.0 as the minimum supported.
To add more information, the problem is that the minos
found in the LC_BUILD_VERSION
section of some of the libs in rust-std
starting on the nightly built of May 08 (this tarball) is set to 16.4. See:
$ wget https://static.rust-lang.org/dist/2024-05-08/rust-std-nightly-aarch64-apple-ios.tar.xz && tar xzvf rust-std-nightly-aarch64-apple-ios.tar.xz
$ otool -lv rust-std-nightly-aarch64-apple-ios/rust-std-aarch64-apple-ios/lib/rustlib/aarch64-apple-ios/lib/libcompiler_builtins-2a62d0fbf20b6004.rlib | grep -A3 LC_BUILD_VERSION
cmd LC_BUILD_VERSION
cmdsize 24
platform IOS
minos 10.0
--
cmd LC_BUILD_VERSION
cmdsize 24
platform IOS
minos 16.4
--
(...)
It's worth noting that LC_VERSION_MIN_IPHONEOS
has been wrong for a while, but since newer toolchains only look at LC_BUILD_VERSION
this wasn't a problem.
Before May 8th the compile units didn't have LC_BUILD_VERSION
at all but after that build, all of them have the incorrect one.
Looks like there were a handful of changes to https://github.com/rust-lang/rust/blob/fd8d6fbe505ecf913f5e2ca590c69a7da2789879/compiler/rustc_target/src/spec/base/apple/mod.rs about 4 months ago. https://github.com/rust-lang/rust/pull/121296 seems like it could have been a candidate. @shepmaster any ideas here?
I'm going to cross post from here, just to keep everyone up to date:
Narrowed down the problem. The problem is that after this change
cc-rs
stopped looking at rustc deployment target (e.g.rustc --target aarch64-apple-ios-sim --print deployment-target
) in favor of just defaulting to the hosts' platform version (e.g.xcrun --show-sdk-platform-version --sdk iphonesimulator
) whenIPHONEOS_DEPLOYMENT_TARGET
is not set.So even if the rest of rust is doing the right thing defaulting to
10.0
, when std includescompiler-builtins
with thec
feature, the units in the compiledlibcompiler-rt.a
archive haveminos
equal to your host tooling and when included, the whole library now is assumed to have that min deploy target.I can think on two options here:
- Set
IPHONEOS_DEPLOYMENT_TARGET
in the ci job that builds the assets to14.0
(this is the minimumcc-rs
would take). or- Bump rustc min targets to something more realistic and get
cc-rs
back to check those numbers.
@rustbot label -I-prioritize -regression-untriaged
I encountered the same problem too. rust 1.82 doesn't seem to have fixed it yet, what is the status of this issue ?
Sorry for the long delay here, I wanted to fix this in cc
proper, but that keeps taking longer than expected.
Have opened https://github.com/rust-lang/rust/pull/133092 to fix it in bootstrap instead for now.
Seeing the following type of warning after upgrading from rust 1.79 to 1.80:
THE FULL LIST OF PROBLEMATIC `.o` FILES
``` lse_cas1_relax.o lse_cas1_acq.o lse_cas1_rel.o lse_cas1_acq_rel.o lse_cas2_relax.o lse_cas2_acq.o lse_cas2_rel.o lse_cas2_acq_rel.o lse_cas4_relax.o lse_cas4_acq.o lse_cas4_rel.o lse_cas4_acq_rel.o lse_cas8_relax.o lse_cas8_acq.o lse_cas8_rel.o lse_cas8_acq_rel.o lse_cas16_relax.o lse_cas16_acq.o lse_cas16_rel.o lse_cas16_acq_rel.o lse_swp1_relax.o lse_swp1_acq.o lse_swp1_rel.o lse_swp1_acq_rel.o lse_swp2_relax.o lse_swp2_acq.o lse_swp2_rel.o lse_swp2_acq_rel.o lse_swp4_relax.o lse_swp4_acq.o lse_swp4_rel.o lse_swp4_acq_rel.o lse_swp8_relax.o lse_swp8_acq.o lse_swp8_rel.o lse_swp8_acq_rel.o lse_ldadd1_relax.o lse_ldadd1_acq.o lse_ldadd1_rel.o lse_ldadd1_acq_rel.o lse_ldadd2_relax.o lse_ldadd2_acq.o lse_ldadd2_rel.o lse_ldadd2_acq_rel.o lse_ldadd4_relax.o lse_ldadd4_acq.o lse_ldadd4_rel.o lse_ldadd4_acq_rel.o lse_ldadd8_relax.o lse_ldadd8_acq.o lse_ldadd8_rel.o lse_ldadd8_acq_rel.o lse_ldclr1_relax.o lse_ldclr1_acq.o lse_ldclr1_rel.o lse_ldclr1_acq_rel.o lse_ldclr2_relax.o lse_ldclr2_acq.o lse_ldclr2_rel.o lse_ldclr2_acq_rel.o lse_ldclr4_relax.o lse_ldclr4_acq.o lse_ldclr4_rel.o lse_ldclr4_acq_rel.o lse_ldclr8_relax.o lse_ldclr8_acq.o lse_ldclr8_rel.o lse_ldclr8_acq_rel.o lse_ldeor1_relax.o lse_ldeor1_acq.o lse_ldeor1_rel.o lse_ldeor1_acq_rel.o lse_ldeor2_relax.o lse_ldeor2_acq.o lse_ldeor2_rel.o lse_ldeor2_acq_rel.o lse_ldeor4_relax.o lse_ldeor4_acq.o lse_ldeor4_rel.o lse_ldeor4_acq_rel.o lse_ldeor8_relax.o lse_ldeor8_acq.o lse_ldeor8_rel.o lse_ldeor8_acq_rel.o lse_ldset1_relax.o lse_ldset1_acq.o lse_ldset1_rel.o lse_ldset1_acq_rel.o lse_ldset2_relax.o lse_ldset2_acq.o lse_ldset2_rel.o lse_ldset2_acq_rel.o lse_ldset4_relax.o lse_ldset4_acq.o lse_ldset4_rel.o lse_ldset4_acq_rel.o lse_ldset8_relax.o lse_ldset8_acq.o lse_ldset8_rel.o lse_ldset8_acq_rel.o aarch64.o absvdi2.o absvsi2.o addtf3.o addvdi3.o addvsi3.o clzdi2.o clzsi2.o cmpdi2.o comparetf2.o ctzdi2.o ctzsi2.o divdc3.o divsc3.o divtf3.o extenddftf2.o extendhfsf2.o extendsftf2.o fp_mode.o fixtfdi.o fixtfsi.o fixtfti.o fixunstfdi.o fixunstfsi.o fixunstfti.o floatditf.o floatsitf.o floatunditf.o floatunsitf.o int_util.o muldc3.o mulsc3.o multc3.o multf3.o mulvdi3.o mulvsi3.o negdf2.o negdi2.o negsf2.o negvdi2.o negvsi2.o paritydi2.o paritysi2.o popcountdi2.o popcountsi2.o powitf2.o subtf3.o subvdi3.o subvsi3.o truncdfhf2.o truncsfhf2.o trunctfdf2.o trunctfsf2.o ucmpdi2.o atomic_flag_clear.o atomic_flag_clear_explicit.o atomic_flag_test_and_set.o atomic_flag_test_and_set_explicit.o atomic_signal_fence.o atomic_thread_fence.o ```Code
I expected not to see an issue with files being built for iOS 16.4 and up only.
Instead, this happened: The compiler complains about the app being built for iOS 15.0 while parts of the binary appear to have been built for iOS 16.4 and up only.
Version it worked on
It most recently worked on: 1.79
Version with regression
1.80