Duplicate artifact tracking issue.

[ehuss]

6308 added a check if multiple jobs produce the same files. To be safe, it is currently a warning. At some point in the future it should be turned into a hard error if no problems are reported. Collisions are almost certainly bad behavior that will cause problems, so rejecting it is probably the right thing to do.

Related issues:

• 5524: Request to warn on duplicate artifact creation — wherein .rmeta files started to collide because bin targets started producing them, and were corrupting one another if built simultaneously. .rmeta collisions fixed in #6292.

• 6293: Handling multiple targets in a workspace with the same name.

• 5444: Hardlink collisions when target is built multiple times (like panic/no-panic). Fixed by #5460 by only hardlinking what was requested.

Known situations where collisions may occur:

• Multiple binary/example/lib targets in a workspace with the same name. (Or reusing a shared target directory.)
• Using --out-dir with an example and binary with the same name.
• Multiple path dependencies with dylibs with the same name.
• Multiple dependencies with the same name and you select both of them on the command-line, for example: cargo build -p rand:0.4.3 -p rand:0.5.5.
• rustdoc in a workspace where multiple crates have the same name. This can arise from a variety of situations (renamed dependencies, multiple versions of a package, different packages with the same crate names, etc.). (rust-lang/rust#56169, rust-lang/rust#61378)
• panic="abort" and cdylibs and tests: Create a project with a lib (cdylib crate type), binary, and an integration test, with panic="abort" in the profile. When cargo test runs, the cdylib is built twice (once with panic=abort for the binary, and once without for the test), with the same filename. Building the lib for the test should probably skip the cdylib crate type (assuming rlib is also available), but implementing this is very difficult. See https://github.com/rust-lang/cargo/issues/6313#issuecomment-480014371.
• Multiple targets (particularly executables) that differ only by case on case-insensitive filesystems.
• PDB collisions on Windows. If the package has a binary and a dylib library of the same name, then the .pdb file for each target will have the same name. This is easy to hit if you have a proc-macro package with a binary.
• Dylib built multiple times with different features
  • for example with new feature resolver, see #9278.
  • and with workspace members, see #12345
• Shared cdylib built with different profile settings, such as a build script and release mode https://github.com/rust-lang/cargo/issues/6313#issuecomment-916741203

Notes on implementation issues:

• Cargo is hard-coded with the outputs that rustc produces. If those outputs change, it will not be able to catch those changes. In particular, #5524 would not have been caught by these checks.
• OutputFile is currently not calculated correctly in some cases. Known issues:
  • Debug files (like .dSYM) are not tracked in some cases because TargetInfo::file_types is making decisions about what should be hardlinked too early. Fixed in #8210
  • It is also very likely that it is missing certain platform differences.
  • Doc outputs are not tracked correctly (it generates incorrect paths). Fixed in #6998.
  • Doctests generate incorrect paths. This should be fixed. Fixed in #6998, doc tests do not have any output paths.
• Not all outputs are checked. Such as:
  • The .d dep info file. This uses the same hash as the main artifact, so is unlikely to be a problem.
  • Incremental files. One hopes that the hashes used in rustc are good enough?
  • Other temp files created by rustc, like rcgu files, which should always include the hash.
  • Anything done by build scripts.
• cargo doc has a dedicated path for detecting collisions. If cargo doc is ever updated to support multiple crates with the same names, this code path can be removed.

[kamathba]

I have an interesting scenario where we are getting this warning that feels a little like a false positive.

We have a project that we can build with x86_64-unknown-linux-gnu or x86_64-unknown-linux-musl. We use a docker container (rust-musl-cross) typically when building for the musl target, since the dependencies are a little harder to set up on everyone's machine. This is also how we build/package in CI. When building with the gnu taget, our output folders are typically target/debug and target/release. When building for the musl target, the output folders are namespaced under target/x86_64-unknown-linux-musl. This diagnostic considers it a warning if using the gnu target I run:

cargo build --release -Z unstable-options --out-dir target/release

Now the why for us doing this has to do more with either nuances or our misunderstandings of how the cargo-deb and cargo-rpm packages work. Since we only ever package from the musl toolchain, we could probably hard-code the paths to target/x86_64-unknown-linux-musl/release/foo inside our Cargo.toml files, but the above scenario seems like a detectable situation where you've selected the output directory that things were going to end up in anyways. It also manifests as a confusing warning:

(using x86_64-unknown-linux-gnu)
cargo build --release -Z unstable-options --out-dir target/release/ 
warning: `--out-dir` filename collision.
The lib target `foo` in package `foo v0.2.0 (/home/bkamath/foo/foo)` has the same output filename as the lib target `foo` in package `foo v0.2.0 (/home/bkamath/foo/foo)`.
Colliding filename is: /home/bkamath/foo/foo/target/release/libfoo.rlib
The exported filenames should be unique.

The same warnings happen for bin targets as well. The two things seemingly being compared in this case aren't created by different targets/build.

[ehuss]

@kamathba Can you clarify some things about your use case for me? I'm trying to understand why you are using --out-dir at all. Are you manually setting the list of files to be packaged? It looks like with cargo-deb you can just specify target/release paths and it rewrites them when cross compiling, so using --out-dir shouldn't be necessary. Can you explain more why you need it?

[kamathba]

@ehuss I think its mostly because of us using both the x86_64-unknown-linux-gnu and x86_64-unknown-linux-musl targets and we want everything to "just work". Also, we use cargo-rpm, which doesn't seem as smart about picking up cross-compile settings and has limited options (which we could probably fix).

All that said, I'm more wondering why cargo can't elide when the --out-dir is the same as the directory it was going to place things in anyways?

As I'm digging into this answer, I'm wondering why our builds default to building for x86_64-unknown-linux-musl even though we don't specify it in .cargo/config. We'd like to not use --out-dir, as its one of the only reasons we aren't on stable now that clippy/rustfmt landed.

[jjpe]

As described here I have a crate in which I'd like to produce both a dylib and a cdylib file.

This seems impossible at the moment. Specifically, Cargo writes both dylibs to the same filename i.e. it seems to write one and then it seems to overwrite it with the other (can't tell you which is which without digging into the final file though). If it is possible to have Cargo produce both cdylib and dylib, I've yet to find out how, as adding crate-type = ["cdylib", "dylib"] to the [lib] section of the crate gives a compile warning leading to this issue.

[Lokathor]

I'm trying to produce rlib, staticlib, and cdylib just to make sure that all modes are buildable (because I've had some tricky build problems once or twice already) and I'm getting a warning from cargo test that told me to come here.

Also, cargo test fails to run if I don't run cargo build first because it tries to link to target/debug/deps/my_lib.dll and fails to find it.

[ehuss]

@Lokathor Can you share a minimum example to demonstrate? I'm not sure how to reproduce your issue. Also, which platform are you on?

[Lokathor]

how about a build log? here's Linux, https://travis-ci.org/Lokathor/thorium/jobs/515790083

the same general warning happens for the mac build too, which you can also find there

on windows, https://ci.appveyor.com/project/Lokathor/thorium/builds/23603097/job/sia07tfchtthym5a (im not 100% sure this is the exact same commit, but it should be)

I don't know how to make a more minimal example. I actually don't even care except for the scary warning that it might become an error later.

[ehuss]

@Lokathor OK, I see what is happening. It is a consequence of having cdylib and panic="abort" with an integration test and a binary. For reasons, cdylibs don't have a unique hash added to their filename. In this case, the "thorium" library needs to be built twice (once with panic="abort" for main.rs, and once without for the test which doesn't allow panic="abort"), and both of those end up with the same filename.

I can't think of an easy workaround for you, unfortunately.

I'm not sure what the best approach here is. Perhaps dylibs could be placed in unique directory names. Also, maybe Cargo could be more conservative what it builds for tests, since it is only linking against one lib type.

[Lokathor]

I only need the dylib for debug and/or release, and even then only if the dynamic_link feature is enabled. It's just a development ability, not meant to be shipped.

Unfortunately, cargo features are currently quite boring and cannot control much. What I would like is if features could control more.

[martinellison]

If you are going to make something a terminating error, could you please make sure that the message sets out the steps that we programmers should follow to fix the error. Otherwise it is like "You have been bad. Compilation prohibited. Goodbye." and then you get all these issues and forum posts.

[SimonSapin]

Documenting Servo produces lots of warnings like:

warning: output filename collision.
The lib target `parking_lot` in package `parking_lot v0.8.0` has the same output filename as the lib target `parking_lot` in package `parking_lot v0.7.1`.
Colliding filename is: /repo/target/doc/parking_lot/index.html
The targets should have unique names.
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>.

This simply becoming a hard error is not acceptable. Having multiple crates with the same name in the dependency graph is a use-case that Cargo needs to support. Even this warning arguably should not exist: this situation is normal, it’s up to Cargo and rustdoc together to figure something out.

[SimonSapin]

Collisions are almost certainly bad behavior that will cause problems, so rejecting it is probably the right thing to do.

In this type of reasoning, please consider: who’s behavior is bad? Who is responsible to fix it? Warnings and errors are only appropriate when the end user is responsible.

Even if the current output is arguably wrong/incomplete, erroring would be a regression.

[ehuss]

@SimonSapin It is a bug. This won't become a hard error until most of the bugs are resolved. Part of the reason of this warning is to ferret out these bugs. Currently it is randomly stomping on files depending on which goes first, so the current behavior is wrong. This warning is just letting you know something is wrong.

We can reword the warning to convey "this is a bug" in the situations where it is a bug. It might be difficult to detect some of the scenarios.

Unfortunately fixing the rustdoc case will be difficult. I think it will require significant changes to rustdoc in order to restructure the directory layout, and have cargo communicate to rustdoc how to link to multiple versions.

[swarnimarun]

I am curious is there a way to select which one of the colliding packages should be used in the doc gen in case of being in a secondary dependency especially if they are two different versions of the same package?

The logs seem to suggest both packages got documented. But only the first one seems to be there. Is there something more to it?

[SimonSapin]

We can reword the warning to convey "this is a bug"

@ehuss Yes, rewording would be good. As a user of cargo doc when I see this:

The targets should have unique names.
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>.

This message is very strongly suggesting that I did something wrong and I should consider changing the names of "targets". (What are targets in this context? Do I even have any control over them?)

But there is nothing wrong with having multiple versions of the same crate in a dependency graph. Cargo was designed from the very beginning to support that scenario.

So it is not users who are doing something wrong, but the historical design of rustdoc (or is it cargo doc?) who incorrectly assumes that crate names are unique and can be used as-is as directory names.

For an eventual fix, maybe cargo doc could detect this situation and add a version number the directory names in that case. cargo vendor already does this.

Until then, yes then emitting a message to warn users of the data loss is better the silently overwriting. But blaming users (with a "we’ll break your stuff" threat!) is very much not the right response.

[ehuss]

is there a way to select which one of the colliding packages should be used in the doc

Unfortunately, no. The one that appears in the final output can be random.

[ehuss]

@SimonSapin Can you explain which situation generated that message with cargo doc? I have updated the message for some of the other situations to make it clearer it is a bug in Cargo, and what is wrong (and are hopefully less "blamey"). But I can't think offhand from that message what scenario causes that more generic message with cargo doc. Maybe a workspace with multiple members with the same executable names?

maybe cargo doc could detect this situation and add a version number the directory names in that case

That is the fix, someone just needs to work on it. It is non-trivial, and requires changes to rustdoc. Cargo has to relay the mapping of dependencies to directory names to rustdoc, and that is difficult, and requires some design work for the interface.

[SimonSapin]

I have updated the message

Oh I hadn’t realized, sorry. I copied the above from my June 2019 comment. In a more recent toolchain the output of cargo doc looks much better, thanks!

https://community-tc.services.mozilla.com/tasks/SXrakGUoSReueo0t3aNm1A/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FSXrakGUoSReueo0t3aNm1A%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log#L363

warning: output filename collision.
The lib target `arrayvec` in package `arrayvec v0.5.1` has the same output filename as the lib target `arrayvec` in package `arrayvec v0.4.6`.
Colliding filename is: /repo/target/doc/arrayvec/index.html
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.

[ijackson]

I am curious is there a way to select which one of the colliding packages should be used in the doc gen in case of being in a secondary dependency especially if they are two different versions of the same package?

It seems in practice possible to influence this as follows:

rm -rf target/doc/CRATE
cargo doc -p CRATE:VERSION
cargo doc

After having run the cargo doc -p, it seems sticky, at least if you don't do a full rebuild by removing target/doc. If the crate is a dependency which you're not changing this is probably good enough in many scenarios...

I think it would be much better if cargo had a better heuristic for which one ended up documented: one with the shallowest dependency path, would be good. Another possible workaround would be to add the thing as an additional dependency with rename-dependency but in #56159 we see that the output directory has the wrong (un-renamed) name.

[grovesNL]

Are case-sensitive public symbols tracked by this issue? For example,

pub const A: u32 = 0u32;
pub const a: u32 = 1u32;

With these symbols, running cargo doc on a case-insensitive filesystem will only create a single constant.a.html or constant.A.html (but not both), even though both symbols are still correctly listed in the sidebar. Currently there doesn't seem to be a warning for this case. It would be great if to create unique filenames to avoid the case-insensitive collision or skip these somehow.

This situation already happens in some crates, e.g. the correct output is displayed on a case-sensitive filesystem in https://wgpu.rs/doc/smithay_client_toolkit/keyboard/keysyms/constant.XKB_KEY_A.html and https://wgpu.rs/doc/smithay_client_toolkit/keyboard/keysyms/constant.XKB_KEY_a.html

[jjpe]

would be great if to create unique filenames to avoid the case-insensitive collision or skip these somehow.

I disagree. As annoying as it is, files need to stay human findable IMO. Having a filename that incorporates a hash of some kind (the most straightforward way to do this) makes that effectively impossible. The real issue is case-insensitive filesystems and a solution needs to be found to tackle the issue at the root rather than just applying hierarchies of patches to try to fix the collateral damage of that root issue.

[grovesNL]

@jjpe could you clarify how the root issue might be fixed otherwise? For example, Windows and macOS will probably never have case-sensitive filesystems by default, so it's not clear how we could avoid this issue on those platforms.

Case-sensitive filenames also cause problems for other tools, like committing cargo doc output to git from a case-sensitive filesystem and later trying to access it from case-sensitive filesystem. This is the problem we're currently hitting and will probably have to workaround by post-processing cargo doc output.

[jjpe]

For example, Windows and macOS will probably never have case-sensitive filesystems by default

And yet that's exactly what should happen if this is to be solved cleanly. They caused the problem, likely before they knew case-insensitive FSs were a major PITA. Any fix other than that is nothing more than a bandaid, and thus solves it only partially, for the project doing the fixing.

[ehuss]

Case-sensitivity in rustdoc is tracked in https://github.com/rust-lang/rust/issues/25879. It's not something Cargo can do anything about (it doesn't parse Rust or have any insight into the structure of the code).

[grovesNL]

@ehuss makes sense, thank you!

[ehuss]

Linking issue #8941, which notes a problem with fingerprinting duplicate executables in a workspace.

[BurntSushi]

I got an error in CI that pointed me to this issue: https://github.com/BurntSushi/fst/runs/2751134172?check_suite_focus=true

I'm here, but I don't understand how to resolve the problem. The error message suggests three solutions:

Consider documenting only one, renaming one, or marking one with doc = false in Cargo.toml.

I'd rather continuing to use cargo doc --all in my workspace to make sure it covers all crates. Renaming one isn't really an option. (The main crate is called fst and the binary crate is called fst-bin with the name of its binary being fst.) The last option, setting doc = false in Cargo.toml, sounds fine to me since I don't need rustdoc output for a binary program. But when I do that, it just says that doc is unused:

warning: /home/andrew/rust/fst/fst-bin/Cargo.toml: unused manifest key: package.doc

[ehuss]

The doc = false is a target setting (goes under [[bin]]), not a package setting (see here).

[BurntSushi]

@ehuss Thanks, that seems to work-around the error, but I still get this warning:

warning: output filename collision.
The lib target `fst` in package `fst v0.4.6` has the same output filename as the lib target `fst` in package `fst v0.4.6 (/home/andrew/rust/fst)`.
Colliding filename is: /home/andrew/rust/fst/target/doc/fst/index.html
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.

Reproduction:

$ git clone -b ag/doc-false https://github.com/BurntSushi/fst
$ cd fst
$ cargo doc --all

Version info:

$ rustc --version
rustc 1.54.0-nightly (c79419af0 2021-06-04)
$ cargo --version
cargo 1.54.0-nightly (0cecbd673 2021-06-01)

[ehuss]

There are two copies of fst in your dependency graph. There is the root fst, and then the one from crates.io (from various dependencies, such as fst-bin and regex-automata). They both output to the doc/fst/ directory. cargo tree --workspace -i https://github.com/rust-lang/crates.io-index#fst:0.4.6 will show where the crates.io copy comes from.

I'm not sure what you are running cargo doc for, but some options are to use --no-deps, or to patch the crates.io copies like this in the root Cargo.toml:

[patch.crates-io]
fst = {path = "."}

[BurntSushi]

OK, I used --no-deps to work around this. It's just a CI check, so building docs for dependencies doesn't matter I suppose.

The problem ended up being that fst was getting pulled in transitively by another crate, which made it quite confusing to debug.

Thanks for your help!

[ijackson]

There are two copies of fst in your dependency graph.

IME this situation is completely normal when running cargo doc. I like to run that, without --no-deps, because I like to have local copies of the documentation for reference, including for all of my dependencies.

I'm not sure what you are running cargo doc for, but some options are to use --no-deps, or to patch the crates.io copies like this in the root Cargo.toml:

Since it is a warning, there is another option: just ignore the warnings. (This probably isn't sensible for @BurntSushi's CI use case.)

As a result of ignoring this warning I have once in my recollection ended up confused by reading docs for a very old version of a crate rather than my direct dependency. I found a workaround for that too: once you've noticed this is happening, you can in practice get it to show you the one you want: https://github.com/rust-lang/cargo/issues/6313#issuecomment-687780103

It would be nice if this problem could be resolved properly. And it would be nice if it could be disentangled from the problem of clashing items on case-insensitive filesystems. I think it should be possible to fix the problem for different versions of the same crate, by renaming all but one of them, without needing to open any further cans of worms.

[ijackson]

$ grep cargo-doc-suppress-errors Makefile
        $(CARGO) doc $(CARGO_DOC_OPTS) --workspace 2>&1 |egrep -vf .cargo-doc-suppress-errors
$ cat .cargo-doc-suppress-errors 
The lib target `.*` in package `.*` has the same output filename as the lib target `.*` in package `.*`.
Colliding filename is:.*
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github\.com/rust-lang/cargo/issues/6313>\.
warning: output filename collision\.
$

[RabidFire]

Hi folks 👋 Just documenting my use case here:

I have a large monorepo with many microservices written in Rust. Right now, they are separate crates (with some shared utility crates). Each crate has its own 'target' directory, so if we build all the services, it takes 100+ GB of disk space on our machines, and the shared crates are built each time.

Tried switching to a cargo workspace after reading that it might be a better way to organize a Rust monorepo. That's when I ran into this "targets should have unique names" warning. Each microservice tries to have consistent target names ("grpc_server", "background_worker", etc), so that we can use the same Dockerfile for all the microservices.

Perhaps the final binary target artifacts could live in the respective crate directories, while the workspace target folder contains all the common build and dep artifacts? Or, maybe workspaces aren't the right way to organize monorepos?

Thanks for all your help! 😄

[tmandry]

Some behavior around this may have changed, causing a failed to remove file error of a duplicated bin target name, as seen in this crater log. That's the only failure like this I see. (rust-lang/rust#87749)

I'm currently not treating this as a bug, since I think these warnings have been around for awhile, but wanted to note it somewhere.

[kaenganxt]

I have a (possibly) different problem with this issue. It seems to be caused by a library that is built as a cdylib and which is also required in a build script. A minimal example can found here: cargo_collision.zip Building this workspace produces the duplicate artifact warning (but only when building in release mode).

In my real setup, I also get a linking error, where the symbols from the communication library cannot be found (Again, only in Release builds, so these two issues seem to be connected). Both issues started appearing once I added the communication lib as a build dependency. This also happened once with the example given above, but I'm not able to reproduce it right now.

Does anyone have an idea what's causing these problems?

[purpleposeidon]

I have a workspace with a member whose name conflicted with an indirect dependency. This makes updating a breaking change.

[ehuss]

@kaenganxt The issue is that build scripts are built without optimization for release builds, so your shared dependency gets built multiple times. However, since it has a cdylib, there is no hash in the filename so there is a collision between the optimized and unoptimized versions.

One option is to change the profile settings so that they are shared again:

[profile.release.build-override]
opt-level = 3

Another option is to always build with the --target flag which will keep the build scripts and other artifacts in separate directories.

I would also try to avoid using dylib dependencies in build scripts altogether. If you can simplify your dependencies, that would be the route I would go.

[kaenganxt]

@ehuss Thank you for the helpful advice. I realized that the dylib wasn't actually needed anymore and a static lib is enough, so the fix was quite easy. But I think that the warning message could be improved. Currently it just says that "libname" has the same file name as "libname", which isn't really helpful. Maybe somehow the fact that makes the difference between the duplicate artifacts (e.g. the opt-level) could be shown?

[vthib]

I also stumbled upon this warning, and I'm not sure to find where they come from. I have managed to do a minimal reproducer for it: reproducer_filename_collision.tar.gz However, this "minimal" reproducer is still quite complex:

• workspace with 3 crates, lets say A, B and C, and with resolver = "2"
• crate A has a crate-type of rlib + cdylib, and a dependency on indexmap
• crate B is a proc_macro crate, and depends on A
• crate C depends on hashbrown

`cargo tree` of the reproducer

``` cdylib v0.1.0 (/home/vthib/tmp/reproducer_filename_collision/cdylib) └── indexmap v1.7.0 └── hashbrown v0.11.2 └── ahash v0.7.6 ├── getrandom v0.2.3 │ ├── cfg-if v1.0.0 │ └── libc v0.2.107 └── once_cell v1.8.0 [build-dependencies] └── version_check v0.9.3 [build-dependencies] └── autocfg v1.0.1 hashbrown_user v0.1.0 (/home/vthib/tmp/reproducer_filename_collision/hashbrown_user) └── hashbrown v0.11.2 (*) proc_macro_crate v0.1.0 (proc-macro) (/home/vthib/tmp/reproducer_filename_collision/proc_macro_crate) └── cdylib v0.1.0 (/home/vthib/tmp/reproducer_filename_collision/cdylib) (*) ```

With this configuration, a cargo build will generate the warning, twice:

Click here for the warnings

``` warning: output filename collision. The lib target `cdylib` in package `cdylib v0.1.0 (/home/vthib/tmp/reproducer_filename_collision/cdylib)` has the same output filename as the lib target `cdylib` in package `cdylib v0.1.0 (/home/vthib/tmp/reproducer_filename_collision/cdylib)`. Colliding filename is: /home/vthib/tmp/reproducer_filename_collision/target/debug/deps/libcdylib.rlib The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see . warning: output filename collision. The lib target `cdylib` in package `cdylib v0.1.0 (/home/vthib/tmp/reproducer_filename_collision/cdylib)` has the same output filename as the lib target `cdylib` in package `cdylib v0.1.0 (/home/vthib/tmp/reproducer_filename_collision/cdylib)`. Colliding filename is: /home/vthib/tmp/reproducer_filename_collision/target/debug/deps/libcdylib.so The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see . ```

Changing the resolver, removing the crate C, removing the proc_macro, removing the cdylib, all those changes remove the warnings. Specifying the target does as well.

Not present in this reproducer is the fact that there does seem to be a real issue underneath this warning. When compiling my project, i often get compilation issues in crate A, issues that can disappear when running cargo again and again with the same options. Those compilation issues can be from rustc, i link them below (those are from my actual project and not the reproducer, so i anonymized them a bit):

Transient compilation errors

``` error[E0277]: the trait bound `for<'de> Config: serde::de::Deserialize<'de>` is not satisfied --> /src/lib.rs:217:50 | 217 | .map(|(v, _)| serde_yaml::from_str::(v).unwrap()) | ^^^^^^ the trait `for<'de> serde::de::Deserialize<'de>` is not implemented for `Config` | ::: /home/vthib/.cargo/registry/src/github.com-1ecc6299db9ec823/serde_yaml-0.8.21/src/de.rs:1442:8 | 1442 | T: DeserializeOwned, | ---------------- required by this bound in `serde_yaml::from_str` | help: trait impl with same name found --> /home/vthib/ | 8 | #[derive(Serialize, Deserialize, Default, ObfDebug)] | ^^^^^^^^^^^ = note: perhaps two different versions of crate `serde` are being used? = note: required because of the requirements on the impl of `serde::de::DeserializeOwned` for `Config` = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info) ``` (there is only a single version of the serde crate being used).

There are also link errors than sometimes happen, that can also disappear when rerunning cargo build.

Unfortunately the compilation & link errors are not present in the reproducer, but understanding the origin of the warnings can probably help in explaining those as well.

I have reproduced it on 1.56 and nightly, but it was iirc already present before 1.56.

[espindola]

A situation where we can hit this issue is when using resolver version 2 and a crate with different features in build-dependencies and dependencies:

[workspace]
resolver = "2"

[package]
name = "api"
version = "0.1.0"

[build-dependencies]
swc_common = { path = "./swc_common", default-features = true }

[dependencies]
swc_common = { path = "./swc_common", default-features = false }

and swc_common has

[lib]
crate-type = ["lib", "dylib"]

[espindola]

A situation where we can hit this issue is when using resolver version 2 and a crate with different features in build-dependencies and dependencies:

At least for this case the only thing that worked for me was to copy the regular dependencies to build-dependencies and then trim. This makes sure that swc_common (in my case), is only built once by matching the features that are used in swc_common and its dependencies.

This effectively does a bit of the old resolver=1 logic :-(

[clarkmcc]

Similar to @espindola, I have a crate that has

[lib]
crate-type = ["lib", "dylib"]

and when running cargo test --all from my workspace, I get the collision, but going to each dependant crate and running cargo test works fine. What is the standard operating procedure for something like this? It doesn't seem like that unusual of a use-case.

[the-emerald]

My program depends on tungstenite 0.17.2 and redis 0.21.5. They depend on sha-1 and sha1 respectively.

warning: output filename collision.
The lib target `sha1` in package `sha1 v0.6.1` has the same output filename as the lib target `sha1` in package `sha-1 v0.10.0`.
Colliding filename is: /home/emerald/discord/collection_watcher/target/doc/sha1/index.html
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.

[TheButlah]

Similar to @espindola, I have a crate that has

[lib]
crate-type = ["lib", "dylib"]

and when running cargo test --all from my workspace, I get the collision, but going to each dependant crate and running cargo test works fine. What is the standard operating procedure for something like this? It doesn't seem like that unusual of a use-case.

I have this exact same problem. @clarkmcc did you find a workaround or a solution?

[clarkmcc]

@TheButlah sadly, no. I'm still waiting for a proper resolution.

[SimonSapin]

As a work-around for this case, could you afford to make the dylib a separate Cargo package? It would then have a separate name, avoiding collisions.

[TheButlah]

Is that really the workaround? It sounds very tedious. If it comes down to it, I'll do it though.

[SimonSapin]

I don’t know if it does what you want, it’s just an idea from reading this thread.

[TheButlah]

As @SimonSapin suggested, I solved this by moving any cdylibs that the crates produce to "leaf nodes" of the dependency graph. In my case, instead of creating simple trivial helper crates that produce cdylibs, I simply stopped emitting cdylibs for transitive dependencies - the only cdylib that gets produced is in one FFI crate.