Add crt-static feature for msvc

[wravery]

I have some static C++ libraries I'd like to link against on Windows with MSVC, and they are built with the /MT flag for the static CRT. If there's a mismatch with any statically linked libraries, the link fails. I can tweak the cc::Build for my own files built with cxx by adding static_crt(true), but there's currently no way to configure the flags for cxx.cc which is built from cxx as part of its own build.rs script.

In my project, I also have a .cargo/config.toml file with this option, which makes the Rust object files link against the static CRT as well:

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

I added that to this change in cxx, but gated on cfg(feature = "crt-static") instead of the triplet, so it can still link the Rust objects with the C++ objects anytime this feature is enabled. Consumers may still need to enable that in their own crates separately, I don't think they'll automatically pick this setting up from the cxx config.toml. But that should only impact consumers who are opting into this feature already.

[dtolnay]

Would it make more sense for the cc crate to handle this by defaulting builds to static_crt(true) when target_feature = "crt-static" is detected?

[wravery]

Would it make more sense for the cc crate to handle this by defaulting builds to static_crt(true) when target_feature = "crt-static" is detected?

Yes, I think you're right. As far as I know, there shouldn't be any cases where cc should compile C/C++ linked to the dynamic CRT DLLs and then try to link those against Rust objects compiled against the static CRT libs, or vice versa. They should always be in sync for the MSVC toolchain.

[dtolnay]

Sounds good — that was my guess. The cc crate is already responsible for communicating with Cargo to instruct rustc to link the result of the cc build. As you said, there is no reason it should run a static_crt=false build and then attempt to get that linked with static_crt=true Rust code.

I'll go ahead and close this while you follow up in the cc repo. Feel free to comment back here if that gets shot down, and we can reevaluate.

[wravery]

It looks like the target-features don't flow from the top crate down to the crates it consumes, at least not if it's scoped to the package's own .cargo/config.toml. If I only set this in my project's .cargo/config.toml, when it builds cxx, the flag is missing and it's not listed in the CARGO_CFG_TARGET_FEATURE output for cxx, but it is used in my project.

It turns out cc also has support for this already by default 😄, but because it's not flowing from the top-level package config.toml down to its dependencies and their dependencies, it doesn't kick in. It does work if you set the RUSTFLAGS environment variable before running cargo, and it works for user-wide ~/.cargo/config.toml as well, but this would let a consumer handle it automatically with feature flags in the Cargo.toml.

[wravery]

@dtolnay apparently I can't re-activate it myself, all I can do is start another PR for the same branch. I can see how not getting to permanently close a PR would get annoying for maintainers, but tagging you here in case you want to re-open this PR with its discussion intact.