Crate-type = ["cdylib", "dylib"] confuses Cargo nowadays

#1

I have a project that has crate-type = ["cdylib", "dylib", "rlib"] under the [lib] section in its Cargo.toml manifest i.e. something like this:

Cargo.toml:

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

Since Rust 1.31 or 1.32, this has resulted in a warning, essentially saying that these options result in artifacts being built with the same name, and thus the combination is invalid.

As far as I can see, it is invalid to define multiple [lib] sections in the Cargo.toml file, so that idea is off the table.

I agree that artifact production clashes are undesirable.
What I’m less clear on is why the warning-and-error-to-be is produced in the first place, rather than Cargo taking care to produce 2 dynamic library files that explicitly don’t clash with one another?

And if I want both a cdylib and a dylib in the same crate, what can I do to resolve this issue right now, aside from using ugly hacks like creating wrapper crates?

#2

What’s not clear to me is what conflict there is in the first place. Don’t dylibs have a hash in their name, while cdylibs don’t?

#3

This is the conflict:

$ cargo run
warning: output filename collision.
The lib target `foo` in package `foo v0.9.0 (/home/j/dev/foo/)` has the same output filename as the lib target `foo` in package `foo v0.9.0 (/home/j/dev/foo/)`.
Colliding filename is: /home/j/dev/foo/target/debug/deps/libfoo.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 https://github.com/rust-lang/cargo/issues/6313
warning: output filename collision.
The lib target `foo` in package `foo v0.9.0 (/home/j/dev/foo/)` has the same output filename as the lib target `foo` in package `foo v0.9.0 (/home/j/dev/foo/)`.
Colliding filename is: /home/j/dev/foo/target/debug/libfoo.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 https://github.com/rust-lang/cargo/issues/6313

So there’s actually a GitHub issue for it.

As for the answer to your question, it appears that both dylibs and cdylibs have no hashes in the filename of the produced .so file.