search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.62k stars 2.4k forks source link

`error adding symbols: file format not recognized` #8239

Closed toku-sa-n closed 4 years ago

toku-sa-n commented 4 years ago

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 (cb06cb269 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. https://github.com/rust-lang/wg-cargo-std-aware/issues/53 seems to be related.

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

Related issue: https://github.com/rust-osdev/cargo-xbuild/issues/69

lights0123 commented 4 years ago

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 4 years ago

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 4 years ago

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:

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

alexcrichton commented 4 years ago

Ok this should be fixed with https://github.com/rust-lang/rust/pull/72325

ehuss commented 4 years ago

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 https://github.com/rust-lang/wg-cargo-std-aware/issues/53.

eira-fransham commented 3 years ago

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.