rust-lang/cargo

`error adding symbols: file format not recognized`

toku-sa-n opened this issue · 6 comments

toku-sa-n commented

Problem

The file format of the output binary of cargo build -Zbuild-std=core,alloc is not recognized.

Steps

  1. Clone https://github.com/toku-sa-n/cargo_bug
  2. git checkout with_rlibc
  3. make

This causes the error: ld: target/cargo_settings/debug/librust_bug.a: error adding symbols: file format not recognized

Possible Solution(s)

Sorry, but I have no idea.

Notes

Output of cargo version:cargo 1.45.0-nightly (cb06cb2 2020-05-08)

rlibc is deprecated, but with compiler_builtins (which is the replacement of rlibc) , cargo build -Zbuild-std=core,alloc itself fails with the error: multiple rlib candidates for compiler_builtins found. rust-lang/wg-cargo-std-aware#53 seems to be related.

Building without compiler_builtins will cause another linker error: undefined reference to 'memcpy'.

Related issue: rust-osdev/cargo-xbuild#69

lights0123 commented

I have this issue on my custom target when specifying lto = true:

  = note: "nspire-gcc" "-L" "/home/benschattinger/Documents/Projects/Calculator/example-nspire/target/sysroot/lib/rustlib/armv5te-nspire-eabi/lib" "/home/benschattinger/Documents/Projects/Calculator/example-nspire/target/armv5te-nspire-eabi/release/deps/async_demo-4f8ee0faccd8ac66.async_demo.42x0nugk-cgu.4.rcgu.o" "-o" "/home/benschattinger/Documents/Projects/Calculator/example-nspire/target/armv5te-nspire-eabi/release/deps/async_demo-4f8ee0faccd8ac66" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/benschattinger/Documents/Projects/Calculator/example-nspire/target/armv5te-nspire-eabi/release/deps" "-L" "/home/benschattinger/Documents/Projects/Calculator/example-nspire/target/release/deps" "-L" "/home/benschattinger/Documents/Projects/Calculator/example-nspire/target/sysroot/lib/rustlib/armv5te-nspire-eabi/lib" "-Wl,--start-group" "-Wl,--end-group" "-Wl,-Bstatic" "/home/benschattinger/Documents/Projects/Calculator/example-nspire/target/sysroot/lib/rustlib/armv5te-nspire-eabi/lib/libcompiler_builtins-3330920514730093.rlib" "-Wl,-Bdynamic" "-Wl,--allow-multiple-definition"
  = note: arm-none-eabi-ld: /home/benschattinger/Documents/Projects/Calculator/example-nspire/target/sysroot/lib/rustlib/armv5te-nspire-eabi/lib/libcompiler_builtins-3330920514730093.rlib: error adding symbols: file format not recognized
          collect2: error: ld returned 1 exit status

This occurs both with cargo-xbuild and -Zbuild-std=core,alloc.

alexcrichton commented

Cargo recently had changes with LTO and optimizing build times by producing object files that are actually LLVM bitcode. I suspect this is a bug where LLVM bitcode is making its way to the linker when it shouldn't.

Would it be possible to minimize this to a small Cargo project perhaps?

alexcrichton commented

Ok I got a chance to dig into this a bit. This is definitely -Zbuild-std-specific.

The problem here is that Cargo is compiling the crate graph with -Clinker-plugin-lto, but crates like compiler-builtins and rlibc do not participate in LTO because they're marked with #![no_builtins].

I think there's a few ways we could fix this:

  • Update rustc to ignore -Clinker-plugin-lto if the crate is marked with #![no_builtins]. I don't think it's basically ever correct for these crates to participate in LTO.
  • Update Cargo to learn about #![no_builtins] and don't pass these flags.
  • Update Cargo with specific knowledge about compiler-builtins and leave rlibc broken.

I'll see if I can whip up a patch to do the first of these.

  • 👍1
alexcrichton commented

Ok this should be fixed with rust-lang/rust#72325

  • 🎉2
ehuss commented

I'm going to close this as fixed, per rust-lang/rust#72325.

There's still some open questions about how compiler-builtins symbols are working -- whether or not it uses the "mem" feature, particularly for JSON spec targets, and how those symbols are exported. I still get undefined references from memcpy to various things in libcore even with the mem feature. Tracking those in rust-lang/wg-cargo-std-aware#53.

eira-fransham commented

I'm getting this issue when compiling under aarch64 Arch Linux (I don't know if it happens on other distros because they have too-old a version of ld and it causes some problems with the latest Clang version). I'm compiling C++ code and linking to it from Rust. Disabling LTO in both clang and cargo fixes the issue. Under x86_64 Arch Linux it works.

  • 👍5