Internal compiler error: building dynamic library is unsupported on Emscripten

[kubkon]

Apologies if this is a duplicate, but I couldn't find a similar issue. Anyhow, the issue appears to be caused when trying to build for wasm32-unknown-emscripten target and including a lib crate with crate-type = ["rlib", "staticlib", "cdylib"] causes the following compiler panic:

thread 'rustc' panicked at 'src/librustc_codegen_ssa/back/linker.rs:878: building dynamic library is unsupported on Emscripten', src/librustc/util/bug.rs:37:26
stack backtrace:
   0:        0x1082d6c55 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9462d4b5888539ab
   1:        0x10830a510 - core::fmt::write::hfc4799bb5f5713e1
   2:        0x1082c977b - std::io::Write::write_fmt::h688ebb99d695121f
   3:        0x1082db053 - std::panicking::default_hook::{{closure}}::h46807e40cc5c9ec9
   4:        0x1082dad5a - std::panicking::default_hook::hfa3fa9913244654c
   5:        0x1025301e2 - rustc_driver::report_ice::h37932e7c4f1fba7f
   6:        0x1082db84c - std::panicking::rust_panic_with_hook::hb7e09606b75e30c0
   7:        0x105974ec5 - std::panicking::begin_panic::hcf494bfc97f475ef
   8:        0x105a61c3c - rustc::util::bug::opt_span_bug_fmt::{{closure}}::h826c2d7833f6f58e
   9:        0x105a503ba - rustc::ty::context::tls::with_opt::{{closure}}::h50671f3cc14a88db
  10:        0x105a5036c - rustc::ty::context::tls::with_opt::ha2373df8753b454e
  11:        0x105a61b68 - rustc::util::bug::opt_span_bug_fmt::h894addd94d24f6bd
  12:        0x105a61abb - rustc::util::bug::bug_fmt::he4d8ec493683828c
  13:        0x10501fa7d - <rustc_codegen_ssa::back::linker::EmLinker as rustc_codegen_ssa::back::linker::Linker>::build_dylib::hd75fbf4112e25780
  14:        0x102753c1e - rustc_codegen_ssa::back::link::link_natively::h710fa9b0482dda87
  15:        0x102751ed2 - rustc_codegen_ssa::back::link::link_binary::h40e7f85745f8fa06
  16:        0x1028a20d7 - <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::join_codegen_and_link::{{closure}}::h48ab3e569fa83cb0
  17:        0x102898d37 - rustc::util::common::time::h0fa921a50246e4dc
  18:        0x10284d7ce - <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::join_codegen_and_link::hff6da34c9bbbb753
  19:        0x102679dcd - rustc_interface::queries::Linker::link::h892d2dbb5d6c10b7
  20:        0x10250011c - rustc_interface::interface::run_compiler_in_existing_thread_pool::ha1b7eef4d8bad1d7
  21:        0x1024d1479 - scoped_tls::ScopedKey<T>::set::he6a052ea9f345ec5
  22:        0x10254c415 - syntax::with_globals::h445b4296ae442554
  23:        0x1024d83cd - std::sys_common::backtrace::__rust_begin_short_backtrace::he6da9f1213f05905
  24:        0x1082eb00f - __rust_maybe_catch_panic
  25:        0x1024e4bc7 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h62a536cce0774879
  26:        0x1082bb66e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h88795daf010cbf80
  27:        0x1082e9f9e - std::sys::unix::thread::Thread::new::thread_start::h731ad860c1aa479e
  28:     0x7fff63737e65 - _pthread_start

error: internal compiler error: unexpected panic

After further investigation, removing the cdylib from crate-type removes the error.

The weird thing is that this issue only seems to appear when building the main crate with cargo rustc instead of cargo build (the reason here involved passing in additional compiler flags). Also, the issue seems to concern all toolchains: 1.40.0-stable, 1.41.0-beta and 1.42.0-nightly.

Anyhow, the error can be replicated by running a build.sh script in wasmtime/crates/wasi-common/js-polyfill crate. For reference, the PR introducing this bit of functionality into wasmtime is bytecodealliance/wasmtime#720.

[jonas-schievink]

Seems like this is just a panic that should instead be a fatal error

[kubkon]

@jonas-schievink hmm, but does that mean if I'd like to use a lib which specifies itself as a dynamic lib using crate-type=[cdylib] amongst others in a binary cross-compiled to Emscripten, I will be greeted with a fatal error unless I remove the cdylib crate-type annotation?

[jonas-schievink]

No, only the cases causing the ICE will instead report a normal error. But it looks like the panic was never supposed to be reached in the first place, so there might be an additional bug.

[kubkon]

Ah, OK, makes sense. Thanks for the clarification!

[pnkfelix]

triage: P-medium, at least to get rid of the ICE and have it signal a fatal error instead. (But the note about there being a potential additional bug does make me wonder what else may be happening here.)