`-C target-feature=crt-static` does not enable `cdylib` for musl when passed as CLI argument to `cargo rustc`

[davidhewitt]

Problem

Try building a cdylib crate with cargo rustc for x86_64-unknown-linux-musl target, using -C target-feature=-crt-static on the command line. This will fail.

e.g. the namespace_package example in setuptools_rust (https://github.com/PyO3/setuptools-rust/tree/main/examples/namespace_package):

$ cd setuptools-rust/examples/namespace_package
$ cargo rustc --lib --target x86_64-unknown-linux-musl -- -C target-feature=-crt-static
error: cannot produce cdylib for `namespace_package_rust v0.1.0 (/home/david/dev/setuptools-rust/examples/namespace_package)` as the target `x86_64-unknown-linux-musl` does not support these crate types

But it does work, as long as the flag is sent in RUSTFLAGS:

$ cd setuptools-rust/examples/namespace_package
$ RUSTFLAGS="-C target-feature=-crt-static" cargo rustc --lib --target x86_64-unknown-linux-musl
    # (compilation output)
    Finished dev [unoptimized + debuginfo] target(s) in 4.09s

Steps

No response

Possible Solution(s)

Looking at src/cargo/core/compiler/build_context/target_info.rs, it looks to me like cargo uses rustc --print=file-names to check whether cdylib crate type is supported:

# Without -C target-feature=-crt-static, `rustc` does not support `cdylib` for this target
$ rustc <(echo "") --crate-type=cdylib --print=file-names --target=x86_64-unknown-linux-musl --crate-name ___
warning: dropping unsupported crate type `cdylib` for target `x86_64-unknown-linux-musl`

warning: 1 warning emitted

# With -C target-feature=-crt-static, `rustc` is happy to crate a cdylib
$ rustc <(echo "") --crate-type=cdylib --print=file-names --target=x86_64-unknown-linux-musl --crate-name ___ -C target-feature=-crt-static
lib___.so

Also in target_info.rs, in TargetInfo::new it looks like the contents of RUSTFLAGS are sent to the rustc --print=file-names invocation but the CLI args passed to cargo rustc are not. That would be consistent with my observations above.

I think a fix is to include these CLI arguments? I am unsure of the possible consequences which is why I didn't author a PR to thread them through and instead wrote a bug report.

Notes

No response

Version

cargo 1.56.0 (4ed5d137b 2021-10-04)
release: 1.56.0
commit-hash: 4ed5d137baff5eccf1bae5a7b2ae4b57efad4a7d
commit-date: 2021-10-04

[ehuss]

Yea, cargo rustc does not use the arguments passed to it when probing the target config. Unfortunately I don't think this would be particularly easy to do, since the flags passed to cargo rustc are intended only for the final artifact being produced. Unfortunately I don't have an easy answer other than to just use RUSTFLAGS instead.

[davidhewitt]

Understood. Presumably there are very few flags which will affect target discovery, so do you think it's reasonable for cargo's behavior to change as per above? Or do you think that carries a risk of unintended breakage?

[ianks]

Just ran into this again. It would be nice to honor CARGO_TARGET_{{target}}_RUSTFLAGS as well if cargo rust arguments are too much of a hassle. I find this approach is better than using RUSTFLAGS directly because it's less likely a user will accidentally clobber it.

example: https://github.com/oxidize-rb/rb-sys/blob/daccdcf7fa39cbe21dcaff968115e70d954d3fd3/docker/Dockerfile.x86_64-linux-musl#L9C5-L9C53