search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
96.91k stars 12.52k forks source link

Panic when trying to link a static library #116091

Open paulyoung opened 12 months ago

paulyoung commented 12 months ago

Code

use std::{env, path::Path};

fn main() {
    let cargo_manifest_dir = env::var("CARGO_MANIFEST_DIR").unwrap();

    println!(
        "cargo:rustc-link-search={}",
        Path::new(&cargo_manifest_dir)
            .join("lib")
            .display()
    );

    println!(
        "cargo:rustc-link-lib=static:+verbatim=mylib.a",
    );
}

Meta

rustc --version --verbose:

rustc 1.74.0-nightly (e4133ba9b 2023-09-22)
binary: rustc
commit-hash: e4133ba9b1a150ef624f5d189913a37405f4414c
commit-date: 2023-09-22
host: aarch64-apple-darwin
release: 1.74.0-nightly
LLVM version: 17.0.0

I'm pretty sure I could also reproduce this on the nightly build of 1.68 from 2022-12-15.

Error output

thread 'rustc' panicked at compiler/rustc_codegen_llvm/src/back/archive.rs:397:67:
called `Option::unwrap()` on a `None` value
Backtrace

``` stack backtrace: 0: 0x1052cc53c - ::fmt::h888d5accfa36c168 1: 0x10531ffb8 - core::fmt::write::h04d9f73f7e836658 2: 0x1052c20ec - std::io::Write::write_fmt::h94e1673c729f9317 3: 0x1052cc37c - std::sys_common::backtrace::print::h10a4fbdfaaae2dd2 4: 0x1052cef78 - std::panicking::default_hook::{{closure}}::h7765bf8325104f29 5: 0x1052cec90 - std::panicking::default_hook::hb5f126536978c525 6: 0x10d8685e8 - as core[f9fe6632a5d6f467]::ops::function::Fn<(&dyn for<'a, 'b> core[f9fe6632a5d6f467]::ops::function::Fn<(&'a core[f9fe6632a5d6f467]::panic::panic_info::PanicInfo<'b>,), Output = ()> + core[f9fe6632a5d6f467]::marker::Sync + core[f9fe6632a5d6f467]::marker::Send, &core[f9fe6632a5d6f467]::panic::panic_info::PanicInfo)>>::call 7: 0x1052cf710 - std::panicking::rust_panic_with_hook::h324900f77a570bad 8: 0x1052cf49c - std::panicking::begin_panic_handler::{{closure}}::he54b71682c96c343 9: 0x1052cc9c8 - std::sys_common::backtrace::__rust_end_short_backtrace::h49b09aa4dc6f1101 10: 0x1052cf248 - _rust_begin_unwind 11: 0x10534b320 - core::panicking::panic_fmt::hfb1f3dbf27828692 12: 0x10534b394 - core::panicking::panic::hae950524f84a2ba6 13: 0x10da8154c - ::build 14: 0x110d00840 - rustc_codegen_ssa[bcfeca12232ca141]::back::link::link_binary 15: 0x10dad6dfc - ::link 16: 0x10d9bcf6c - ::link 17: 0x10d881ff4 - rustc_span[b8fa0d11b7a16384]::set_source_map::, rustc_interface[609b5eee07ebfc53]::interface::run_compiler, rustc_driver_impl[36007714369cb99c]::run_compiler::{closure#1}>::{closure#0}::{closure#0}> 18: 0x10d8664b4 - std[7f4e316fde1c09b8]::sys_common::backtrace::__rust_begin_short_backtrace::, rustc_driver_impl[36007714369cb99c]::run_compiler::{closure#1}>::{closure#0}, core[f9fe6632a5d6f467]::result::Result<(), rustc_span[b8fa0d11b7a16384]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[f9fe6632a5d6f467]::result::Result<(), rustc_span[b8fa0d11b7a16384]::ErrorGuaranteed>> 19: 0x10d867624 - <::spawn_unchecked_, rustc_driver_impl[36007714369cb99c]::run_compiler::{closure#1}>::{closure#0}, core[f9fe6632a5d6f467]::result::Result<(), rustc_span[b8fa0d11b7a16384]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[f9fe6632a5d6f467]::result::Result<(), rustc_span[b8fa0d11b7a16384]::ErrorGuaranteed>>::{closure#1} as core[f9fe6632a5d6f467]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} 20: 0x1052d85b8 - std::sys::unix::thread::Thread::new::thread_start::hb31de041cbbaf8e4 21: 0x1acbd9240 - __pthread_deallocate error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: please attach the file at `/Users/py/projects/paulyoung/power-player/main/rustc-ice-2023-09-23T05:08:39.149995Z-34553.txt` to your bug report note: compiler flags: --crate-type staticlib --crate-type cdylib -C opt-level=z -C panic=abort -C lto -Z unstable-options -C target-cpu=cortex-m7 -C link-args=--emit-relocs -C relocation-model=pic -C panic=abort note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack warning: `power_player` (lib) generated 2 warnings error: could not compile `power_player` (lib); 2 warnings emitted Error: cargo failed with error ExitStatus(unix_wait_status(25856)) ```

Relevant compiler source code

https://github.com/rust-lang/rust/blob/e4133ba9b1a150ef624f5d189913a37405f4414c/compiler/rustc_codegen_llvm/src/back/archive.rs#L390-L397

paulyoung commented 12 months ago

Any suggestions or workarounds would be appreciated. Thanks.

saethlin commented 12 months ago

I tried and I can't reproduce a panic. The build script code you provided is not on its own sufficient to produce this panic, it seems to depend on at least one of what exactly is in the crate that this build script is for, what is in mylib.a, or filesystem state surrounding these.

Based on the panicking code, I bet it's something about the archive.

paulyoung commented 11 months ago

Not sure how much I can share of the archive yet but when I run ar -t on the archive, the first two lines of output are:

/
//

Is that somehow problematic?

saethlin commented 11 months ago

Yes. Do you have any idea what made this archive?

paulyoung commented 11 months ago

It was built using arm-none-eabi-gcc, arm-none-eabi-g++, and arm-none-eabi-ar.

paulyoung commented 11 months ago

Is there anything further I can do to help move this along?

nikic commented 11 months ago

Can you please share the arm-none-eabi-ar command producing this archive?

paulyoung commented 11 months ago

This is obfuscated but should give you the idea.

/nix/store/6akp770yzkvlyc8sr749fvv8zillshi8-gcc-arm-embedded-12.2.rel1/bin/arm-none-eabi-ar rcs mylib.a ../source/core/Foo.o ../source/core/Bar.o <lots more .o files> ../mylib/mylib.o produces mylib.a

/nix/store/6akp770yzkvlyc8sr749fvv8zillshi8-gcc-arm-embedded-12.2.rel1/bin/arm-none-eabi-ar -t result/lib/mylib.a prints:

/
//
Foo.o
Bar.o
...
<lots more .o files>
...
mylib.o

In case it's relevant, I accidentally ran the above with ar (/nix/store/fb4rdxr69sy1vsi98z3njxjzdq3rj3ah-clang-wrapper-11.1.0/bin/ar) and it printed:

__.SYMDEF SORTED
/
//
Foo.o
Bar.o
...
<lots more .o files>
...
mylib.o
bjorn3 commented 11 months ago

Is it possible you have been mixing an ar which emits GNU style archives with one emitting BSD or Mach-O (apple) style ones? You seem to have a symbol table for both styles, which is not a valod archive.

paulyoung commented 10 months ago

Everything is being built with the Arm GNU toolchain as far as I can tell. nm does complain that truncated or malformed archive (offset to next archive member past the end of the archive after member) so I'll look into that. Thanks.