Skip to content

warning: output filename collision #15423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wdanilo opened this issue Apr 12, 2025 · 4 comments
Closed

warning: output filename collision #15423

wdanilo opened this issue Apr 12, 2025 · 4 comments
Labels
C-bug Category: bug S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.

Comments

@wdanilo
Copy link

wdanilo commented Apr 12, 2025

Problem

Hi, let's imagine I have this siutation:

workspace:

  • Cargo.toml (members: [crates/*])
  • crates
    • lib/Cargo.toml
    • macro/Cargo.toml
    • helper/Cargo.toml

Now, lib imports helper and macro imports helper. When I build it, cargo tells me:

output filename collision.
The lib target `helper` in package `helper v1.0.0 (<mylib>/crates/helper)` has the same output filename as the lib target `helper` in package `helper v1.0.0 (<mylib>/crates/helper)`.
Colliding filename is: <mylib>/target/release/deps/libhelper.rlib
The targets should have unique names.

And I believe this is because lib and macro use other rustc config to compile their targets. What to do in this situation?

Steps

  1. Replicate struct shown above.

Possible Solution(s)

None so far

Notes

No response

Version

cargo 1.85.0-nightly (c86f4b3a1 2024-12-24)
@wdanilo wdanilo added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Apr 12, 2025
@weihanglo
Copy link
Member

Thanks for the report! Do you have a minimal reproducible example we can inspect? Like a Git repo, or a zip file would help. IIRC, rlib under target/release/deps/ directory shouldn't collide with each others, so I am curious.

@weihanglo weihanglo added S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. and removed S-triage Status: This issue is waiting on initial triage. labels Apr 12, 2025
@weihanglo
Copy link
Member

Anyway, there is a mega tracking issue of this #6313.

@wdanilo
Copy link
Author

wdanilo commented Apr 18, 2025

I just realized it happens only when shared target contains cdylib. Without it, it compiles fine. The minimal repro is basically empty libs as described above.

@weihanglo
Copy link
Member

Without knowing the content of each Cargo.toml file, I cannot really reproduce it. That said, you mentioned cdylib so I can guess from that crate-type being set as cdylib. Dylib filename collision is tracked in #6313, so close in favor of that. Let us know if there is a reason to keep this open separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.
Projects
None yet
Development

No branches or pull requests

2 participants