error adding symbols: file format not recognized
#8239
Comments
|
I have this issue on my custom target when specifying This occurs both with cargo-xbuild and |
ehuss
added
A-linkage
|
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? |
|
Ok I got a chance to dig into this a bit. This is definitely The problem here is that Cargo is compiling the crate graph with 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. |
This commit updates the code generation for `#![no_builtins]` to always produce object files instead of conditionally respecting `-Clinker-plugin-lto` and sometimes producing bitcode. This is intended to address rust-lang/cargo#8239. The issue at hand here is that Cargo has tried to get "smarter" about codegen in whole crate graph scenarios. When LTO is enabled it attempts to avoid codegen on as many crates as possible, opting to pass `-Clinker-plugin-lto` where it can to only generate bitcode. When this is combined with `-Zbuild-std`, however, it means that `compiler-builtins` only generates LLVM bitcode instead of object files. Rustc's own LTO passes then explicitly skip `compiler-builtins` (because it wouldn't work anyway) which means that LLVM bitcode gets sent to the linker, which chokes most of the time. The fix in this PR is to not actually respect `-Clinker-plugin-lto` for `#![no_builtins]` crates. These crates, even if slurped up by the linker rather than rustc, will not work with LTO. They define symbols which are only referenced as part of codegen, so LTO's aggressive internalization would trivially remove the symbols only to have the linker realize later that the symbol is undefined. Since pure-bitcode never makes sense for these libraries, the `-Clinker-plugin-lto` flag is silently ignored.
|
Ok this should be fixed with rust-lang/rust#72325 |
…to, r=nnethercote Always generated object code for `#![no_builtins]` This commit updates the code generation for `#![no_builtins]` to always produce object files instead of conditionally respecting `-Clinker-plugin-lto` and sometimes producing bitcode. This is intended to address rust-lang/cargo#8239. The issue at hand here is that Cargo has tried to get "smarter" about codegen in whole crate graph scenarios. When LTO is enabled it attempts to avoid codegen on as many crates as possible, opting to pass `-Clinker-plugin-lto` where it can to only generate bitcode. When this is combined with `-Zbuild-std`, however, it means that `compiler-builtins` only generates LLVM bitcode instead of object files. Rustc's own LTO passes then explicitly skip `compiler-builtins` (because it wouldn't work anyway) which means that LLVM bitcode gets sent to the linker, which chokes most of the time. The fix in this PR is to not actually respect `-Clinker-plugin-lto` for `#![no_builtins]` crates. These crates, even if slurped up by the linker rather than rustc, will not work with LTO. They define symbols which are only referenced as part of codegen, so LTO's aggressive internalization would trivially remove the symbols only to have the linker realize later that the symbol is undefined. Since pure-bitcode never makes sense for these libraries, the `-Clinker-plugin-lto` flag is silently ignored.
|
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 |
|
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. |
Problem
The file format of the output binary of
cargo build -Zbuild-std=core,allocis not recognized.Steps
git checkout with_rlibcmakeThis causes the error:
ld: target/cargo_settings/debug/librust_bug.a: error adding symbols: file format not recognizedPossible Solution(s)
Sorry, but I have no idea.
Notes
Output of
cargo version:cargo 1.45.0-nightly (cb06cb2 2020-05-08)rlibcis deprecated, but withcompiler_builtins(which is the replacement ofrlibc) ,cargo build -Zbuild-std=core,allocitself 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_builtinswill cause another linker error:undefined reference to 'memcpy'.Related issue: rust-osdev/cargo-xbuild#69
The text was updated successfully, but these errors were encountered: