This is a pretty weird one; we bumped into this due to a bad combination of Linux Docker containers running with mounted volumes on a Mac host and trying to build with stale artifacts. I made a repo that reproduces this ICE at https://github.com/jgallagher-cs/rustc-ice.
We have a C file (foo.c in the reproducer repo) that was compiled into a library on Linux (a CentOS 6 Docker container, although I suspect that doesn't matter too much):
gcc -c foo.c -o foo.o
ar cr libfoo.a foo.o
The library file itself was then copied to a Mac (running Catalina), where foo.c was recompiled and ar was used again to update libfoo.a:
clang -c foo.c -o foo.o
ar cr libfoo.a foo.o # NOTE: updates the linux libfoo.a
I very much doubt this should work and don't know enough about the archive format (and the differences between Linux and Mac ar implementations) to know exactly what's going wrong, but if you then try to link this library on a Mac with rustc, I hit an ICE.
Code
No Rust code is involved here other than a build script instructing cargo to link a library; e.g.,
fn main() {
println!("cargo:rustc-link-search=foo-mac");
println!("cargo:rustc-link-lib=static=foo");
}Meta
rustc --version --verbose:
rustc 1.44.0 (49cae5576 2020-06-01)
binary: rustc
commit-hash: 49cae55760da0a43428eba73abcb659bb70cf2e4
commit-date: 2020-06-01
host: x86_64-apple-darwin
release: 1.44.0
LLVM version: 9.0
I believe a coworker confirmed the same ICE on 1.44.1.
Error output
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/librustc_codegen_llvm/back/archive.rs:274:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.44.0 (49cae5576 2020-06-01) running on x86_64-apple-darwin
note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib
note: some of the compiler flags provided by cargo are hidden
error: could not compile `rustc-ice`.
To learn more, run the command again with --verbose.
Backtrace
stack backtrace:
0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
1: core::fmt::write
2: std::io::Write::write_fmt
3: std::panicking::default_hook::{{closure}}
4: std::panicking::default_hook
5: rustc_driver::report_ice
6: std::panicking::rust_panic_with_hook
7: rust_begin_unwind
8: core::panicking::panic_fmt
9: core::panicking::panic
10: <rustc_codegen_llvm::back::archive::LlvmArchiveBuilder as rustc_codegen_ssa::back::archive::ArchiveBuilder>::build
11: rustc_session::utils::<impl rustc_session::session::Session>::time
12: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::link
13: rustc_interface::queries::Linker::link
14: rustc_interface::interface::run_compiler_in_existing_thread_pool
15: scoped_tls::ScopedKey<T>::set
16: rustc_ast::attr::with_globals
This is a pretty weird one; we bumped into this due to a bad combination of Linux Docker containers running with mounted volumes on a Mac host and trying to build with stale artifacts. I made a repo that reproduces this ICE at https://github.com/jgallagher-cs/rustc-ice.
We have a C file (
foo.cin the reproducer repo) that was compiled into a library on Linux (a CentOS 6 Docker container, although I suspect that doesn't matter too much):The library file itself was then copied to a Mac (running Catalina), where
foo.cwas recompiled andarwas used again to updatelibfoo.a:I very much doubt this should work and don't know enough about the archive format (and the differences between Linux and Mac
arimplementations) to know exactly what's going wrong, but if you then try to link this library on a Mac with rustc, I hit an ICE.Code
No Rust code is involved here other than a build script instructing cargo to link a library; e.g.,
Meta
rustc --version --verbose:I believe a coworker confirmed the same ICE on 1.44.1.
Error output
Backtrace