zld fails to link build script of backtrace-rs

michaeleisel / zld

A faster version of Apple's linker

MIT License

1.19k stars 50 forks source link

zld fails to link build script of backtrace-rs #94

Closed TheOnlyMrCat closed 2 years ago

TheOnlyMrCat commented 3 years ago

I'm using zld through cargo with rustflags: "-C", "link-arg=-fuse-ld=/usr/local/bin/zld".

Compilation fails with the following warning and error:

ld: warning: ignoring file [project directory]/target/debug/deps/libcc-2e31f8b39e273fe3.rlib, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
          Undefined symbols for architecture x86_64:

          [A number of symbols from the `core`, `alloc`, `std`, and `cc` crates, referenced variously from `core`, `alloc`, `std`, and `build_script_build::build_android`]

ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Attached is the full log, if it is helps: backtrace-rs_report.txt

Compilation succeeds using the default Apple linker

michaeleisel commented 3 years ago

Can you provide steps for a minimal reproducible example?

TheOnlyMrCat commented 3 years ago

Sure! Steps to reproduce:

As a dependency:

Create a new cargo project (or use an existing one)
Add backtrace = "0.3.62" to Cargo.toml (The most recent version at the time of writing)
Run cargo build

Building the repository itself:

Clone https://github.com/rust-lang/backtrace-rs (Tested on commit 67d0df3, tagged as 0.3.62)
Run cargo build in the cloned repository.

michaeleisel commented 2 years ago

Building with cargo clean && RUSTFLAGS="-C link-arg=-fuse-ld=/path/to/zld" cargo build succeeds for me for backtrace-rs

michaeleisel commented 2 years ago

Also, it looks like you're on an Intel mac, is that true?

TheOnlyMrCat commented 2 years ago

Curiously, the bug has disappeared for me as well. (Yes, intel mac, now on Monterey, same commit, with zld versions 1.3.1 and 1.3.3)

michaeleisel commented 2 years ago

hmm i'm curious of two things:

is the linking deterministic? (does it produce the same executable each time?)
can you try removing /tmp/zld-* and then running it twice? to test cached and non-cached cases

TheOnlyMrCat commented 2 years ago

The MD5 sum of target/debug/build/backtrace-*/build-script-build remains consistent, even when removing /tmp/zld-*.

I might have a time machine backup, so I could attempt to replicate the issue on a VM

michaeleisel commented 2 years ago

well, if the bug has disappeared, we can close. feel free to report if it happens again