Output file collision for PDB debug info when package builds both [lib] and [bin]

[t-rapp]

Starting with Cargo v1.45.0 a file collision warning is printed when building a project that generates a shared library (DLL) together with a static binary (EXE):

warning: output filename collision.
The bin target `foo-bar` in package `foo-bar v0.1.0 (C:\Daten\RustEval\TestCargoPdb)` has the same output filename as the lib target `foo_bar` in package `foo-bar v0.1.0 (C:\Daten\RustEval\TestCargoPdb)`.
Colliding filename is: C:\Daten\RustEval\TestCargoPdb\target\debug\deps\foo_bar.pdb
The output filenames should be unique.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
If this looks unexpected, it may be a bug in Cargo. Please file a bug report at
https://github.com/rust-lang/cargo/issues/ with as much information as you
can provide.
cargo 1.45.0 (744bd1fbb 2020-06-15) running on `x86_64-pc-windows-msvc` target `x86_64-pc-windows-msvc`
First unit: Unit { pkg: Package { id: PackageId { name: "foo-bar", version: "0.1.0", source: "C:\\Daten\\RustEval\\TestCargoPdb" }, ..: ".." }, target: TargetInner { name: "foo-bar", tested: false, ..: with_path("C:\\Daten\\RustEval\\TestCargoPdb\\src\\main.rs", Edition2018) }, profile: Profile { ..: default_dev() }, kind: Host, mode: Build, features: [] }
Second unit: Unit { pkg: Package { id: PackageId { name: "foo-bar", version: "0.1.0", source: "C:\\Daten\\RustEval\\TestCargoPdb" }, ..: ".." }, target: TargetInner { ..: lib_target("foo_bar", ["rlib", "cdylib"], "C:\\Daten\\RustEval\\TestCargoPdb\\src\\lib.rs", Edition2018) }, profile: Profile { ..: default_dev() }, kind: Host, mode: Build, features: [] }

File Cargo.toml is:

[package]
name = "foo-bar"
version = "0.1.0"
edition = "2018"

[lib]
name = "foo_bar"
crate-type = ["rlib", "cdylib"]

[[bin]]
name = "foo-bar"
test = false
doc = false

[dependencies]

The library and binary target names differ in using underscores vs. hyphen characters, but apparently the PDB output file for the binary target is foo_bar.pdb instead of foo-bar.pdb. When looking into the target\debug\deps folder it seems that the temporary binary output file is named target\debug\deps\foo_bar.exe and then later copied into target\debug\foo-bar.exe, converting from underscore to hyphen, while the PDB file keeps the underscore as the (absolute!) filename is stored within the executable file.

It might be better to directly generate EXE and PDB output files using the configured binary target name.

[ehuss]

Thanks for the report!

One possible solution I see here is to use the -o flag to specify the output filename (particularly for binary executables). I haven't really thought through the consequences, so that might introduce new problems. @alexcrichton can you think of potential problems with that? Also, relatedly, do you happen to know exactly what the --crate-name flag does? (cc rust-lang/reference#541 where I would like to get it documented) I've never been entirely clear, especially when it comes to building executables. In this case, it is responsible for setting the output filename with an underscore. Removing --crate-name would avoid that (though would still need to use -o in case the filename was different from the target name).

[t-rapp]

One possible solution I see here is to use the -o flag to specify the output filename (particularly for binary executables).

Just to clarify: You suggest that Cargo calls rustc with -o flag? Or the user shall call cargo build with -o (could not find that flag in cargo help)?

[alexcrichton]

Ah yeah this would be Cargo calling rustc with -o, not as a flag to Cargo. (nothing I think can be done at your level right now about this without code changes in Cargo)

@ehuss that seems reasonable to me, and I think it should fix this issue (but haven't tested). I believe the --crate-name flags and -o are sort of tied at the hip for libraries but otherwise for binaries/staticlib/cdylib/etc AFAIK --crate-name affects both the internal crate name (used for some macros and such) and the output file name. Other than that I don't think it affects too much else (probably some hashing internally), but I could be wrong since it's an extremely old feature of rustc (predates me) and has been tweaked quite a lot over time...

[NikolaTotev]

Not sure how relevant/helpful this would be to anyone reading, but I also encountered this warning as of August 2023, but everything seems to work fine for now.