cargo build with a build-dependency that is a cdylib results in a warning

[turtleslow]

cargo build emits the following warning when in the Cargo.toml under [build-dependencies] I include a crate of type crate-type = ["cdylib"] (the crate-type is specified in the dependency's Cargo.toml). The warning does not show if I modify the dependency's Cargo.toml to compile with crate-type = ["dylib"]. However, I need the library to be a cdylib.

warning: The package `some_crate` provides no linkable target. The compiler might raise an error while compiling `build_script_build`. Consider adding 'dylib' or 'rlib' to key `crate-type` in `some_crate`'s Cargo.toml. This war
ning might turn into a hard error in the future.

[lukaslueg]

Do we ignore crate-type for build-dependencies to force being linkable? If so, this needs some extra filtering. Otherwise I think the warning is correct.

[ehuss]

The warning seems correct. The build script will not link against a cdylib. Can you explain more what you are trying to do? Why do you need a cdylib? What do you expect rustc to do with it?

[turtleslow]

I would like to make an so that is linkable from C but also from Rust. Further, I would like to have this library as a dependency in a rust binary, where I'm using dlopen() and dlsym() to link via the FFI. This works nicely with cargo because the so ends up in the search path without special configurations under cargo build and cargo run. The only slight bother is the warning which states it may be turned into a hard error. If I should be doing this differently I'm happy to do so.

[lukaslueg]

While unusual, imho depending on something which is linked manually is a legitimate use-case. This was explicitly considered in #4797. The reason for the strong warning is that cargo can't predict if linking will indeed fail if non-linkable targets are built, a situation leading to confusing error messages.

It was also considered in #4797 that we might need an escape hatch which allows signaling that the user is aware that the target may not be linkable, suppressing the warning.

[ehuss]

An escape hatch sounds reasonable. There might be a bigger discussion around dealing with dependency crate types (it has come up a number of times).

As for the original report, is there a reason you are using build-dependencies instead of normal dependencies? build-dependencies are intended for build.rs scripts. I would think in this case it should be a normal dependency.

[turtleslow]

I had initially set up a build script but didn't really need it. Though since this particular binary depends on the so only through the FFI rather than the using the crate as a standard dependency (and could alternatively use a pure C implementation I have) it seemed more similar in use to a build dependency than a standard dependency.

[kennykerr]

I also recently noticed this problem in window-rs (microsoft/windows-rs#2545). I certainly hope it does not become a "hard error in the future". 😊

[lukaslueg]

The original PR #4797 fixed a bad - that is, non existent - error message. We deliberately turned this into a warning instead of an error, as legitimate use cases might arise at a later time. Almost seven years have now passed since the original bug report, and there have been numerous requests to un-threat-ify the warning. IMHO the argument between "we might not be able to support this" vs. "hold my beer and watch this" comes down on the side of the beer. If there are no fundamental reasons that break Cargo (especially in hypothetical dependency-of-dependency cases, breaking upstream builds), this should be accepted behavior. Because it is.

[kennykerr]

Various examples of "hold my beer and watch this" can be found in https://github.com/microsoft/windows-rs

Please don't break me. 🙏