output filename collision with `panic = "abort"`

[d-e-s-o]

Problem

Let's say I have:

cargo init foobar
cd foobar
cat >> Cargo.toml <<EOF
[lib]
name = "foobar"
crate-type = ["cdylib", "rlib"]
EOF
# Make it binary + lib combo (as is common in many small size projects)
touch src/lib.rs

# It builds fine:
cargo build --all-targets --release

Now I add

cat >> Cargo.toml <<EOF
[profile.release]
panic = "abort"
EOF

Suddenly I get:

$ cargo build --all-targets -r
warning: output filename collision at libfoobar.so
  |
  = note: the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)` has the same output filename as the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)`
  = note: this may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>
  = help: consider changing their names to be unique or compiling them separately
warning: output filename collision at libfoobar.so.dwp
  |
  = note: the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)` has the same output filename as the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)`
  = note: this may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>
  = help: consider changing their names to be unique or compiling them separately
warning: output filename collision at libfoobar.rlib
  |
  = note: the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)` has the same output filename as the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)`
  = note: this may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>
  = help: consider changing their names to be unique or compiling them separately

The reason, it seems, is that tests implicitly use panic = "unwind" and that causes a duplicate library build of the library (correct me if that is wrong): one with abort and one with unwind. Okay, I suppose it makes sense to have tests ignore the crate-wide setting for a release build.

And yet, this is a nightmare:

• it's unclear to a user why such a setting would cause this warning
• it's a time sink to debug that, as the warnings don't even really make any sense:

  the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)`has the same output filename as
  the lib target `foobar` in package `foobar v0.1.0 (/tmp/foobar)`

• so the same target in the same package has the same output file name? Aha?

Steps

see above

Possible Solution(s)

That tests using this setting seems to be an implementation detail to the degree I can tell. As such, I'd expect it to know what it's doing and disambiguate. Why can't it use a hashed foobar thing in that case, for example? Ultimately the final consumable object could just be a cheap hardlink and, in the case of tests, there wouldn't be any because there is no user-facing consumable (sorry if I am not using the proper terminology here; I hope what I am trying to say came across nevertheless). Hence, there would be no collision either.

Notes

No response

Version

cargo 1.93.0-nightly (083ac5135 2025-12-15) (gentoo)
release: 1.93.0-nightly
commit-hash: 083ac5135f967fd9dc906ab057a2315861c7a80d
commit-date: 2025-12-15
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.17.0 (sys:0.4.83+curl-8.15.0 system ssl:OpenSSL/3.5.5)
os: Gentoo Linux 2.18.0 [64-bit]

[ehuss]

Thanks for the report! I agree it is pretty confusing and frustrating. I think this case is tracked in #6313, so I'm not sure is there something additional that this needs a separate issue?

[epage]

The warning seems to go away when you enable -Zbuild-dir-new-layout (#15010).

[d-e-s-o]

Thanks for the report! I agree it is pretty confusing and frustrating. I think this case is tracked in #6313, so I'm not sure is there something additional that this needs a separate issue?

It's a tracking issue and didn't seem like the right place for a concrete instance to be reported, but I could be wrong.

The warning seems to go away when you enable -Zbuild-dir-new-layout (#15010).

Interesting, I will run with that then. In that case it's probably fine to close, as I assume the new directory layout will reach prime time eventually. Thanks!