panic=immediate-abort with build-std doesn't work: the crate core was compiled with a panic strategy which is incompatible

[burningtnt]

I‘ve tried this code:

name: Build
run: |
  rustup target add --toolchain nightly x86_64-unknown-linux-gnu
  rustup component add rust-src --toolchain nightly-x86_64-unknown-linux-gnu
  cargo +nightly build --release \
    -Z build-std=core,std,alloc,proc_macro,panic_abort \
    -Z build-std-features=default,optimize_for_size
env:
  RUSTFLAGS: -Zunstable-options -Cpanic=immediate-abort

with Cargo.toml

[profile.release]
panic = "abort"

I expected to see this happen: Cargo successfully compiled the project with immediate-abort flag and locally built std package.

Instead, this happened:

error: the crate `core` was compiled with a panic strategy which is incompatible with `immediate-abort`

I'm currently working on burningtnt/Terracotta#54 . All related metadata or configuration can be found on this branch.

[Fulgen301]

Shot in the dark: Does it work if you use -Z build-std-features=default,optimize_for_size,panic_immediate_abort and get rid of -Cpanic=immediate-abort?

[burningtnt]

Shot in the dark: Does it work if you use -Z build-std-features=default,optimize_for_size,panic_immediate_abort and get rid of -Cpanic=immediate-abort?

It worked in the past with legacy nightly rust versions. However, this commit migrated std-feature panic_immediate_abort to panic=immediate-abort, causing a compile-time error. See https://github.com/burningtnt/Terracotta/actions/runs/17974316362/job/51124082970

[saethlin]

You need to pass a --target to put Cargo into cross-compile mode, otherwise the RUSTFLAGS get applied to build scripts and proc macros.

We should probably have another special-case diagnostic for encountering this scenario. You're hitting the special case diagnostic that realizes that core is incompatible so instead of mentioning all the sysroot crates, just say core. But that's not helpful here.

[saethlin]

You may want to do --target $(rustc --print host-tuple). That's what I do instead of trying to remember if I'm on an x86 or Arm system.

[Wyvern]

I hit the same problem, -Zbuild-std failed when using -Cpanic=immediate-abort.

[burningtnt]

You need to pass a --target to put Cargo into cross-compile mode, otherwise the RUSTFLAGS get applied to build scripts and proc macros.

--target $(rustc --print host-tuple) solved my issue. (See https://github.com/burningtnt/Terracotta/actions/runs/18006320572 However, this will modify the original build folder structure, as the binary artifact is redirected to target/${host-tuple}/release/${binary}.

By the way, I'm curious about why cargo cann't handle these cases here automatically. Basically, in the current implemetation of Cargo, users who want to use build-std and immediate-abort features at the same time must adding an extra --target argument, which is not documented anywhere else. Even worse, Cargo produces an incorrect solution here.

[zraineri]

Already passing —target and experiencing this still. Passing —target-dir as well, could that be causing an issue?

[saethlin]

@zraineri Can you compile with the --verbose flag, which will make Cargo print all the rustc invocations, and share those here?

[zraineri]

@saethlin I stripped down the call to:

cargo clean && cargo rustc --release --target=aarch64-apple-darwin --verbose -- -Z unstable-options -C panic=immediate-abort

which gives (pathing reduced):

rustc
--crate-name minimal_panic_immediate_abort
--edition=2024
main.rs
--error-format=json
--json=diagnostic-rendered-ansi,artifacts,future-incompat
--diagnostic-width=113
--crate-type bin
--emit=dep-info,link
-C opt-level=3
-C embed-bitcode=no
--check-cfg 'cfg(docsrs,test)'
--check-cfg 'cfg(feature, values())'
-C metadata=b7565bdae7d2a0de
-C extra-filename=-edac2c0c926f5e3e
--out-dir /target/aarch64-apple-darwin/release/deps
--target aarch64-apple-darwin
-C strip=debuginfo
-L dependency=/target/aarch64-apple-darwin/release/deps
-L dependency=/target/release/deps
-Z unstable-options
-C panic=immediate-abort

I found it gives the same 'core' error with or without build-std

[saethlin]

I think your use case doesn't work because you are using cargo rustc to avoid applying panic=immediate-abort to the sysroot. The error is supposed to indicate that you can't do this and the panic strategy must be applied to the sysroot, but it was probably my mistake to model it after the existing panic incompatibility diagnostic.

[zraineri]

I was unaware there was a difference in affect on sysroot when using cargo rustc vs cargo build, we use it because we pass a large, dynamic list of flags down and it seemed like the more straightforward way to go.

I'll look into using cargo build instead. Really appreciate your time and quick responses on this