Repository navigation
IPHONEOS_DEPLOYMENT_TARGET not followed for some object files #137326
Copy link
Copy link
Closed
Labels
C-bugCategory: This is a bug.Category: This is a bug.O-iosOperating system: iOSOperating system: iOS
Description
I'm developing a internal SDK and I have to build it for iOS:
IPHONEOS_DEPLOYMENT_TARGET=13.0 cargo build --target=aarch64-apple-iosI expected the static library output would follow the IPHONEOS_DEPLOYMENT_TARGET all the way through when checking with otool:
Expected output
Archive : target/aarch64-apple-ios/debug/libmylibrary.a
target/aarch64-apple-ios/debug/libmylibrary.a(mylibrary.001qxyu3qsjczz20kuhn46b2i.rcgu.o):
Load command 0
cmd LC_SEGMENT_64
cmdsize 1112
segname
vmaddr 0x0000000000000000
vmsize 0x000000000000107a
fileoff 1272
filesize 4218
maxprot rwx
initprot rwx
nsects 13
flags (none)
Section
sectname __text
segname __TEXT
addr 0x0000000000000000
size 0x0000000000000014
offset 1272
align 2^2 (4)
reloff 5496
nreloc 1
type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
reserved1 0
reserved2 0
Section
sectname __debug_loc
segname __DWARF
addr 0x0000000000000014
size 0x0000000000000039
offset 1292
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __debug_abbrev
segname __DWARF
addr 0x000000000000004d
size 0x00000000000000d2
offset 1349
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __debug_info
segname __DWARF
addr 0x000000000000011f
size 0x0000000000000463
offset 1559
align 2^0 (1)
reloff 5504
nreloc 2
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __debug_aranges
segname __DWARF
addr 0x0000000000000582
size 0x0000000000000030
offset 2682
align 2^0 (1)
reloff 5520
nreloc 1
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __debug_str
segname __DWARF
addr 0x00000000000005b2
size 0x00000000000004b4
offset 2730
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_names
segname __DWARF
addr 0x0000000000000a66
size 0x0000000000000058
offset 3934
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_objc
segname __DWARF
addr 0x0000000000000abe
size 0x0000000000000024
offset 4022
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_namespac
segname __DWARF
addr 0x0000000000000ae2
size 0x0000000000000198
offset 4058
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_types
segname __DWARF
addr 0x0000000000000c7a
size 0x00000000000002e0
offset 4466
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __compact_unwind
segname __LD
addr 0x0000000000000f60
size 0x0000000000000020
offset 5208
align 2^3 (8)
reloff 5528
nreloc 1
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __eh_frame
segname __TEXT
addr 0x0000000000000f80
size 0x0000000000000048
offset 5240
align 2^3 (8)
reloff 5536
nreloc 2
type S_COALESCED
attributes NO_TOC STRIP_STATIC_SYMS LIVE_SUPPORT
reserved1 0
reserved2 0
Section
sectname __debug_line
segname __DWARF
addr 0x0000000000000fc8
size 0x00000000000000b2
offset 5312
align 2^0 (1)
reloff 5552
nreloc 1
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Load command 1
cmd LC_BUILD_VERSION
cmdsize 24
platform IOS
minos 13.0
sdk n/a
ntools 0
Load command 2
cmd LC_SYMTAB
cmdsize 24
symoff 5560
nsyms 6
stroff 5656
strsize 256
Load command 3
cmd LC_DYSYMTAB
cmdsize 80
ilocalsym 0
nlocalsym 4
iextdefsym 4
nextdefsym 1
iundefsym 5
nundefsym 1
tocoff 0
ntoc 0
modtaboff 0
nmodtab 0
extrefsymoff 0
nextrefsyms 0
indirectsymoff 0
nindirectsyms 0
extreloff 0
nextrel 0
locreloff 0
nlocrel 0
...
Instead, some object files were compile with a different IOS target version (17.2) as we can see in the minos of LC_BUILD_VERSION:
Actual output
target/aarch64-apple-ios/debug/libmylibrary.a(f3c5cc7ab326d4d0-atomic_thread_fence.o):
Load command 0
cmd LC_SEGMENT_64
cmdsize 872
segname
vmaddr 0x0000000000000000
vmsize 0x00000000000004bb
fileoff 1048
filesize 1211
maxprot rwx
initprot rwx
nsects 10
flags (none)
Section
sectname __text
segname __TEXT
addr 0x0000000000000000
size 0x0000000000000034
offset 1048
align 2^2 (4)
reloff 2264
nreloc 2
type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
reserved1 0
reserved2 0
Section
sectname __const
segname __TEXT
addr 0x0000000000000034
size 0x0000000000000005
offset 1100
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes (none)
reserved1 0
reserved2 0
Section
sectname __debug_abbrev
segname __DWARF
addr 0x0000000000000039
size 0x000000000000006a
offset 1105
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __debug_info
segname __DWARF
addr 0x00000000000000a3
size 0x000000000000009b
offset 1211
align 2^0 (1)
reloff 2280
nreloc 4
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __debug_str
segname __DWARF
addr 0x000000000000013e
size 0x00000000000001b9
offset 1366
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_names
segname __DWARF
addr 0x00000000000002f7
size 0x000000000000003c
offset 1807
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_objc
segname __DWARF
addr 0x0000000000000333
size 0x0000000000000024
offset 1867
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_namespac
segname __DWARF
addr 0x0000000000000357
size 0x0000000000000024
offset 1903
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __apple_types
segname __DWARF
addr 0x000000000000037b
size 0x000000000000004e
offset 1939
align 2^0 (1)
reloff 0
nreloc 0
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
sectname __debug_line
segname __DWARF
addr 0x00000000000003c9
size 0x00000000000000f2
offset 2017
align 2^0 (1)
reloff 2312
nreloc 1
type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Load command 1
cmd LC_BUILD_VERSION
cmdsize 24
platform IOS
minos 17.2
sdk 17.2
ntools 0
Load command 2
cmd LC_LINKER_OPTIMIZATION_HINT
cmdsize 16
dataoff 2320
datasize 8
Load command 3
cmd LC_SYMTAB
cmdsize 24
symoff 2328
nsyms 3
stroff 2376
strsize 40
Load command 4
cmd LC_DYSYMTAB
cmdsize 80
ilocalsym 0
nlocalsym 2
iextdefsym 2
nextdefsym 1
iundefsym 3
nundefsym 0
tocoff 0
ntoc 0
modtaboff 0
nmodtab 0
extrefsymoff 0
nextrefsyms 0
indirectsymoff 0
nindirectsyms 0
extreloff 0
nextrel 0
locreloff 0
nlocrel 0
...
In total 1578 but only 145 had these behavior of setting the minos 17.2. Is this behavior expected?
Meta
rustc --version --verbose:
rustc 1.84.1 (e71f9a9a9 2025-01-27)
binary: rustc
commit-hash: e71f9a9a98b0faf423844bf0ba7438f29dc27d58
commit-date: 2025-01-27
host: x86_64-apple-darwin
release: 1.84.1
LLVM version: 19.1.5
Addtional information that can be relevant:
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
C-bugCategory: This is a bug.Category: This is a bug.O-iosOperating system: iOSOperating system: iOS
Activity
bjorn3 commentedon Feb 21, 2025
Those object files are part of the precompiled compiler-builtins crate. They probably need to be compiled with
IPHONEOS_DEPLOYMENT_TARGETset to the minimum iOS version we support.joao-victor-silva commentedon Feb 21, 2025
Good, I'm trying to validate this but so far I didn't find the usage of the compiler-builtins crate, I've tryied the command
cargo tree --target=aarch64-apple-ios --all-featuresand I've got the following output:cargo tree output
I know that some of those crates can use the compiler-builtins, like the bitflags crate, but is an optional dependency, so I can say for shure if the compiler-builtins is or isn't in use. There is another way to check its usage? And what crate is using it? If I knew this I can compile the dependency if the right iOS target.
edit: forgot to put the output in a code block
bjorn3 commentedon Feb 21, 2025
Compiler-builtins is a part of the standard library which is shipped in precompiled form with rustc.
joao-victor-silva commentedon Feb 21, 2025
I can be wrong but this way how compiler-builtins is shipped with rustc looks like a core part of the compiler, not being easy to change, right?
I'm thinking how I can circunvent this issue for now, maybe downgrade the compiler version to a older one that compile with the iOS target that I need or compile everything (compiler-builtins + rustc) by myself and compile the project with it. Any of these solutions would work?
bjorn3 commentedon Feb 21, 2025
If you are using nightly, you can use
IPHONEOS_DEPLOYMENT_TARGET=13.0 cargo build -Zbuild-std=std --target=aarch64-apple-iosto rebuild the standard library including compiler-builtins with the lower deployment target.madsmtm commentedon Feb 23, 2025
I think this is a duplicate of #128419, which was fixed in #133092. Please try the latest nightly? Then the pre-compiled files should have the version 10.0.
Otherwise, as @bjorn3 said, if you want all files to have the same deployment target (usually unnecessary), you will need
-Zbuild-std.joao-victor-silva commentedon Feb 25, 2025
With the
-Zbuild-std=stdworked, thank you everyone 😁 . I think that we can close the issue.madsmtm commentedon Feb 26, 2025
Feel free to close it yourself ;)
ospfranco commentedon Jul 19, 2025
The proposed solution is not ideal. Using nightly puts you on the bleeding edge, with all the troubles that brings. I switched to nightly, but just got hit with a nightly regression that completely kills our CI pipelines
Is there no other workaround this?
VorpalBlade commentedon Jul 19, 2025
@ospfranco in general you should if using nightly stick to a fixed nightly version, and only bump that every so often. You could perhaps update to the nightly that corresponds to a specific stable release branch point.
ospfranco commentedon Jul 19, 2025
yeah, I have resorted to pinning to the latest working version, good tip :)
Still... some other workaround may be possible now?
VorpalBlade commentedon Jul 19, 2025
Can't help you with that unfortunately. I haven't used a mac since the early 2000s (pre-OS X).
hanna-kruppe commentedon Jul 19, 2025
If I’m reading the above comments correctly, the workaround of -Zbuild-std shouldn’t be necessary any more since #133092 was merged and released as part of Rust 1.86 — the precompiled object files should now have an older deployment target so they’re compatible with every iOS version supported by Rust. If you still get too-new deployment targets in some object files, I’d suggest opening a new issue for that because it may be a new regression.
ospfranco commentedon Jul 20, 2025
I just tested the stable channel and the warning seems to be gone! Thanks!