Tracking issue for `rustc-cdylib-link-arg` transitive warning

[ehuss]

In the 1.50 release, there was an unintended change that the cargo:rustc-cdylib-link-arg build script instruction started passing arguments to transitive cdylib dependencies. Previously this was ignored. In the 1.54 release, a warning was added to indicate that this may be rejected in the future.

If you see this warning, you are encouraged to change the way linker arguments are added. Only the build script of the package containing the cdylib should issue cargo:rustc-cdylib-link-arg in its build script. If there is common code for determining these flags that users may need, then an option is to have a build-dependency which provides that logic.

[thomcc]

It seems like if you have:

• crate A with crate-type=["cdylib", "rlib"], that emits println!("cargo:rustc-cdylib-link-arg=...") in its build.rs, and
• crate B of type cdylib that depends on crate A

We'll apply the link args from A to both cdylibs (expected, given the current workaround), but fail to emit the warning, even though the 2nd crate is getting the cdylib args transitively (unfortunate, since that would probably break if we started rejecting transitive cdylib-link-args).

I'm not sure the best way to handle this though, but I figured I'd mention it here.

[cyphar]

It should be noted that this warning appears even if you explicitly set --crate-type=cdylib with cargo rustc as suggested by https://github.com/rust-lang/rust/issues/91632:

cargo rustc --features=capi --crate-type=staticlib
warning: [email protected]+dev: cargo:rustc-cdylib-link-arg was specified in the build script of pathrs v0.0.2+dev (/home/cyphar/src/libpathrs), but that package does not contain a cdylib target

Allowing this was an unintended change in the 1.50 release, and may become an error in the future. For more information, see <https://github.com/rust-lang/cargo/issues/9562>.
   Compiling pathrs v0.0.2+dev (/home/cyphar/src/libpathrs)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.72s

(And if this was turned into a hard error, I guess we would be expected to create a separate feature or pass --cfg=cdylib so that build.rs only emits this when building cdylibs?)

[novafacing]

This accidental change is extremely useful for me. We build a set of sys bindings (https://github.com/novafacing/qemu-rs) that are expected to be built into a cdylib as a transitive dependency. At that point, we can pass cdylib link args to make the cdylib compile gracefully, which makes the previous approach (weak symbols) unnecessary.