Cross-compiling from x86_64-linux to aarch64-darwin produces a broken (stripped) dylib

[badboy]

I am cross-compiling from a Linux x86_64 host to aarch64-apple-darwin.
Since Rust 1.87.0 this results in a broken dylib file when it gets stripped.
This worked ok until 1.86.0

Unfortunately I'm not able to reproduce that on a really small example, but a reproduction case is available in https://github.com/badboy/rocketscience/tree/broken-dylib

Note that this requires additional tooling:

• A clang that can build for that target. The Firefox CI has one like that.
• cctools that support that target, available in cctools-port, and ready built by Firefox CI.
• The macOS SDK. Available at https://github.com/phracker/MacOSX-SDKs/releases/tag/11.3

The included run.sh downloads all requirements and sets RUSTFLAGS accordingly.
All that is required is:

./run.sh

RUSTFLAGS is this:

export RUSTFLAGS="-C linker=${clangdir}/bin/clang -C link-arg=-fuse-ld=${cctoolsdir}/bin/aarch64-apple-darwin-ld -C link-arg=-B -C link-arg=${cctoolsdir}/cctools/bin -C link-arg=-target -C link-arg=aarch64-apple-darwin -C link-arg=-isysroot -C link-arg=${sdkdir}/MacOSX11.0.sdk -C link-arg=-Wl,-syslibroot,${sdkdir}/MacOSX11.0.sdk -C link-arg=-Wl,-dead_strip"

The final dylib at target/aarch64-apple-darwin/release/librocketscience.dylib should be inspectable by aarch64-apple-darwin-nm.
When it's not it will error out.

On Rust 1.87.0 and 1.89.0-nightly (99e7c15 2025-06-01) it fails:

$PWD/tools/cctools/bin/aarch64-apple-darwin-nm: object: target/aarch64-apple-darwin/release/librocketscience.dylib malformed object (section contents at offset 367912 with a size of 936, overlaps section contents at offset 32768 with a size of 338140)

On Rust 1.86.0 or when setting strip = false in Cargo.toml it works:

0000000000007be8 T _ffi_rocketscience_uniffi_contract_version

This is all due to the bundled rust-objcopy.
Manually running the rust-objcopy command on the not-broken dylib that cargo also runs produces the broken dylib:

~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-objcopy --strip-debug target/aarch64-apple-darwin/release/librocketscience.dylib

This does NOT happen when building on my aarch64 macOS machine, only when cross-compiling.

This all sounds very similar to #138212.
Back then it was an upstream bug, so this might be another one.
Or is this due to mixing and matching the toolchains in an incompatible way?

Version it worked on

rustc 1.86.0 (05f9846f8 2025-03-31)
binary: rustc
commit-hash: 05f9846f893b09a1be1fc8560e33fc3c815cfecb
commit-date: 2025-03-31
host: x86_64-unknown-linux-gnu
release: 1.86.0
LLVM version: 19.1.7

Version with regression

rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-unknown-linux-gnu
release: 1.87.0
LLVM version: 20.1.1

[apiraino]

Hmm we had a few recent issues related to linking on macOS but they were something else (linking just failed for a number of reasons¹).

Another suspect I could think of is the LLVM update: does this reproduce right before we merged LLVM 20 in #135763?

cc @nikic if this smells like an LLVM-related issue

Footnotes

1. included Apple seemingly moving to ld-prime on Xcode 16, see rust#141306 ↩

[nikic]

Might be llvm/llvm-project#141494?

[nikic]

cc @dianqk

[badboy]

Hmm we had a few recent issues related to linking on macOS but they were something else (linking just failed for a number of reasons1).

Another suspect I could think of is the LLVM update: does this reproduce right before we merged LLVM 20 in #135763?

cc @nikic if this smells like an LLVM-related issue

Footnotes

1. included Apple seemingly moving to ld-prime on Xcode 16, see [rust#141306](https://togithub.com/rust-lang/rust/issues/141306) [↩](#user-content-fnref-1-2c02945b85ec8e52fbec93365e22d8cb)

cargo-bisect-rustc says it's 87e60a7, so indeed the commit that pulled in the LLVM fix for #138212

Command I ran:

export RUST_SRC_REPO=~/src/rust/rust
cargo bisect-rustc \
  --access=checkout \
  --start=1.86.0 \
  --end=1.87.0 \
  --preserve \
  --target=aarch64-apple-darwin \
  --with-src \
  -v \
  --script run.sh

with run.sh from the rocketscience repo, just slightly adjusted to not rustup component install and using CARGO_TARGET_DIR to find the dylib

[dianqk]

Thw minimal reproduction on macOS:

#![crate_type = "cdylib"]

#[unsafe(no_mangle)]
pub fn foo() {
    panic!();
}

rustc lib.rs -Clink-arg=-ld_classic --target aarch64-apple-ios -o repro.ios.out
llvm-objcopy repro.ios.out repro.ios.stripped.out
llvm-otool -l repro.ios.out | grep LC_ENCRYPTION_INFO
llvm-otool -l repro.ios.stripped.out | grep LC_ENCRYPTION_INFO
cmd LC_ENCRYPTION_INFO_64
llvm-otool: error: 'repro.ios.stripped.out': truncated or malformed object (section contents at offset 223704 with a size of 648, overlaps section contents at offset 32768 with a size of 203768)

rustc lib.rs -Clink-arg=-ld_classic -Clink-arg=-Wl,-encryptable --target aarch64-apple-darwin -o repro.darwin.out
llvm-objcopy repro.darwin.out repro.darwin.stripped.out
llvm-otool -l repro.darwin.out | grep LC_ENCRYPTION_INFO
llvm-otool -l repro.darwin.stripped.out | grep LC_ENCRYPTION_INFO

cmd LC_ENCRYPTION_INFO_64
llvm-otool: error: 'repro.darwin.stripped.out': truncated or malformed object (section contents at offset 223624 with a size of 648, overlaps section contents at offset 32768 with a size of 203300)

But I'm not sure why LC_ENCRYPTION_INFO is being submitted by default here for aarch64-apple-darwin.

[dianqk]

Might be llvm/llvm-project#141494?

Perhaps we should revert all the relevant commits.

[dianqk]

-C link-arg=-Wl,-no_encryption can be used as a workaround for aarch64-apple-darwin.

[badboy]

Might be llvm/llvm-project#141494?

Perhaps we should revert all the relevant commits.

But it did fix the iOS crash. And we probably don't want to regress that again.

Thanks for the minimal reproduction.
I'll test our build with your workaround.

[dianqk]

Might be llvm/llvm-project#141494?

Perhaps we should revert all the relevant commits.

But it did fix the iOS crash. And we probably don't want to regress that again.

Thanks for the minimal reproduction. I'll test our build with your workaround.

We can revert both llvm/llvm-project#120995 and llvm/llvm-project#130517.

[apiraino]

Assigning priority (discussion on Zulip).

@rustbot label -I-prioritize +P-high