Combination of `panic="abort"` and `-Zbuild-std` causes build failure

[AngelicosPhosphoros]

I have tried this on ubuntu and alpine docker containers.

Steps:

1. Install dependencies
   ubuntu: apt update && apt install curl clang
   alpine: apk add curl clang musl-dev

2. Try to build project:

curl --proto '=https' --tlsv1.3 -sSf https://sh.rustup.rs | sh
export PATH="$HOME/.cargo/bin:$PATH"
rustup override set nightly
rustup component add rust-src
cargo new test_build_std --vcs none
cd test_build_std
echo '[profile.release]' >> Cargo.toml
echo 'panic = "abort"' >> Cargo.toml
cargo build --release -Zbuild-std

I expected to see this happen: project successfully compiles

Instead, this happened: build failed with the following error

Alpine:

error[E0152]: duplicate lang item in crate `core`: `sized`
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from /test_build_std/target/x86_64-unknown-linux-musl/release/deps/libcore-ea86b8bdb00db001.rlib, /test_build_std/target/x86_64-unknown-linux-musl/release/deps/libcore-ea86b8bdb00db001.rmeta
  = note: second definition in `core` loaded from /root/.rustup/toolchains/nightly-x86_64-unknown-linux-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-8c023576fd012662.rlib

For more information about this error, try `rustc --explain E0152`.
error: could not compile `test_build_std` (bin "test_build_std") due to 1 previous error

Ubuntu:

error[E0152]: duplicate lang item in crate `core`: `sized`
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from /test_build_std/target/release/deps/libcore-521f42810889a0fe.rlib, /test_build_std/target/release/deps/libcore-521f42810889a0fe.rmeta
  = note: second definition in `core` loaded from /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-62c8dfa7db58d93c.rlib

For more information about this error, try `rustc --explain E0152`.
error: could not compile `test_build_std` (bin "test_build_std") due to 1 previous error

Meta

rustc --version --verbose:

rustc 1.90.0-nightly (4b55fe199 2025-08-01)
binary: rustc
commit-hash: 4b55fe199cfe9c710555a5af7f2a49491ad38254
commit-date: 2025-08-01
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.8

rustc 1.90.0-nightly (4b55fe199 2025-08-01)
binary: rustc
commit-hash: 4b55fe199cfe9c710555a5af7f2a49491ad38254
commit-date: 2025-08-01
host: x86_64-unknown-linux-musl
release: 1.90.0-nightly
LLVM version: 20.1.8

As I understand, the main problem is panic="abort", if I don't use that, build finishes successfully.

[lst15]

I was able to reproduce this issue outside of Docker as well, using the same nightly toolchain (1.90.0). The problem appears to be independent of the environment.

It seems like panic = "abort" triggers an alternate panic runtime setup in the standard library, and when used with -Zbuild-std, it causes a conflict between locally rebuilt artifacts and the precompiled ones from the toolchain. Specifically, libcore ends up being included twice, leading to the duplicate lang item error (E0152: duplicate lang item in crate 'core': 'sized').

As a workaround, removing the panic = "abort" setting allows the build to succeed. This suggests a lack of compatibility between build-std and the abort panic strategy in current nightly builds.

If this combination is fundamentally unsupported, it might be worth adding a diagnostic in Cargo to catch it earlier and emit a clearer error or warning.

[bjorn3]

I believe you need -Zbuild-std-features=panic_abort to build libpanic_abort as needed by libstd for panic=abort.

[saethlin]

Or -Zbuild-std=std,panic_abort

[ChrisDenton]

Yeah, there's no panic_abort std feature. You just have to recompile all relevant crates when building with panic=abort.
E.g.: -Zbuild-std=core,alloc,panic_abort,std. You may or may not need to cargo clean first (you shouldn't usually need to but I have gotten into a messed up state before).

[AngelicosPhosphoros]

That worked, thanks!
Maybe it is a good idea to update default behaviour to recompile panic crate too?

[ChrisDenton]

The current implementation is quite rough around the edges but there's a project goal that aims to design a minimal viable product suitable for stabilisation. Hopefully they'll be an RFC within the next 6 months that people can comment on. One of the "design axioms" is to treat these crates as less special then they currently are which I think might cover this case. But we'll see.