Repository navigation
Closed
Labels
A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Approximate file tree:
├── Cargo.lock
├── Cargo.toml
├── src
│ └── main.rs
└── test_dylib
├── Cargo.toml
└── lib.rs
Top-level Cargo.lock:
[profile.release]
lto = true
[dependencies]
test_dylib = { path = "test_dylib" }
test_dylib/Cargo.toml:
[lib]
path = "lib.rs"
crate-type = ["dylib"]
[profile.release]
lto = true
Snippet of output from RUST_BACKTRACE=1 cargo build --release --verbose:
Running `rustc --crate-name test_package src/main.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C metadata=7e778ca5edc7bd6e -C extra-filename=-7e778ca5edc7bd6e --out-dir /src/test_package/target/release/deps -L dependency=/src/test_package/target/release/deps --extern test_dylib=/src/test_package/target/release/deps/libtest_dylib.so -L native=/src/test_package/target/release/build/ring-9d649aa185d933e6/out`
thread 'rustc' panicked at 'assertion failed: !is_full_lto_enabled(sess)', librustc_trans/back/link.rs:1318:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at libstd/sys_common/backtrace.rs:59
at libstd/panicking.rs:380
3: std::panicking::default_hook
at libstd/panicking.rs:396
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:576
5: std::panicking::begin_panic
6: rustc_trans::back::link::link_args
7: rustc_trans::back::link::link_natively
8: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::join_trans_and_link::{{closure}}
9: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::join_trans_and_link
10: rustc_driver::driver::compile_input
11: rustc_driver::run_compiler
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.25.0 (84203cac6 2018-03-25) running on x86_64-unknown-linux-gnu
error: Could not compile `test_package`.
Caused by:
process didn't exit successfully: `rustc --crate-name test_package src/main.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C metadata=7e778ca5edc7bd6e -C extra-filename=-7e778ca5edc7bd6e --out-dir /src/test_package/target/release/deps -L dependency=/src/test_package/target/release/deps --extern test_dylib=/src/test_package/target/release/deps/libtest_dylib.so -L native=/src/test_package/target/release/build/ring-9d649aa185d933e6/out` (exit code: 101)
Metadata
Metadata
Assignees
Labels
A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
michaelwoerister commentedon May 3, 2018
Thanks for the bug report, @zachreizner!
cc @alexcrichton
alexcrichton commentedon May 3, 2018
This could either be construed as a bug where it should ignore
-C ltowhen compiling crates with dylib deps, or a bug in rustc as it should just do "as much LTO as it can" which means skipping crates that come in through dylibs. I'd be fine either way!matthiaskrgr commentedon May 3, 2018
Is this related to #45689 ?
alexcrichton commentedon May 3, 2018
Yes it's probably the same or a very similar assertion
Michel-Haber commentedon Jul 18, 2018
@alexcrichton any update on this?
alexcrichton commentedon Jul 18, 2018
No, as far as I know no work has happened on this
bjorn3 commentedon Jul 13, 2023
As of #101403 on nightly
-Zdylib-ltocan now be passed if you want to LTO a rust dylib.bjorn3 commentedon Aug 28, 2025
This shouldn't crash anymore. And for allowing LTO with dylib at all it works on nightly with
-Zdylib-ltoand #31854 is still open.