rustc always links against non-debug Windows runtime

[jdm]

When building rust-mozjs with debug symbols enabled, the underlying C++ library links against the debug Windows runtime (msvcrtd.lib) rather than the regular one (msvcrt.lib). Unfortunately, rustc always links against msvcrt.lib unconditionally:

rust/src/vendor/libc/src/windows.rs

Line 150 in da2ce22

#[link(name = "msvcrt")]

. This makes it impossible to build a debug-enabled version of rust-mozjs on Windows.

[jdm]

Would there be any objection to doing something like:

#[cfg(all(target_env = "msvc", debug))] // " if " -- appease style checker
#[link(name = "msvcrtd")]
extern {}

#[cfg(all(target_env = "msvc", not(debug_assertions)))] // " if " -- appease style checker
#[link(name = "msvcrt")]
extern {}

cc @retep998

[retep998]

We already have a feature for choosing whether to link the static or dynamic CRT. It would be a fairly trivial matter to add another feature to choose whether to link the debug or release CRT (which I did suggest but nobody seemed to notice). I'd rather not tie this sort of thing to whether optimizations are enabled.

[jdm]

@retep998 says that the way to fix this is to find the relevant bits in #37545 and duplicate it for crt-debug.

[nox]

#37545 landed, what is needed to make some progress on this?

[retep998]

@nox As I said before, someone has to find the relevant bits in #37545 and duplicate it for crt-debug.

[asajeffrey]

This cost me a couple of days debugging why debugmozjs builds of mozjs_sys were failing with link errors under msvc.

[Neurrone]

Would love to be able to configure this as well for c++ code.

[jdm]

It would make sense to transfer this issue to https://github.com/rust-lang/libc now that the responsible code is in that repository, but I don't have the permissions to do so.

[gnzlbg]

cc @alexcrichton @retep998 @newpavlov - please review the libc C PR at: rust-lang/libc#1433 - I'm not sure how this will interact with linking libc both via libstd and crates.io, what happens if the features are different in each, what happens if the binary is #[no_std] and no libstd is linked, etc.

[retep998]

Solving this issue requires changes both in rust and libc.

[gnzlbg]

Since libstd depends on libc, and libc would need to be compiled differently for debug and release on windows, wouldn't we need to ship two libstds one for debug and one for release ?

[retep998]

Only if there are actual changes to the bindings in libc depending on debug vs release. Simply linking to a different CRT is already handled in std's libc using deferred linking decisions.

[upsuper]

This looks like a pretty big footgun, and it can cause mysterious runtime error taking people lots of time to figure out. Until this gets fixed, there should probably be some document / compiler message warning about this, so that people know that they need to have their C/C++ program always link against the non-debug crt.

[nox]

I'm curious how this can be done cleanly, when the base windows target itself adds -lmsvcrt directly into the link args.

[ChrisDenton]

I really want to find a way forward here as it's a common issue when trying to integrate Rust with existing C/C++ builds.

I do find it slightly odd that linking the C runtime is the responsibility of the libc crate on Windows. That seems unusual compared to other platforms? But ok, I can live with that.

@petrochenkov suggested adding a feature in people's Cargo.toml, which seems a bit odd for this? Like I'm not entirely clear how this will work in practice without special Cargo support, otherwise it puts a lot of the effort of supporting this onto crate authors. A global --cfg (i.e. set in rustflags) might work better. It is super important that everything agrees on which CRT to use. Though I'm still not clear on the benefits of --cfg over a compiler codegen option.

So to sum up I think to do this outside of rustc will require changes to:

• libc needs additional #[link(name = "...", cfg(...))] options
• cc needs to be able understand these target cfgs
• rustc needs to document that the special cfg name(s) are reserved for this use

Is that right?

Btw, there should also be an option to not link a CRT. This is the default for no_std on Windows but is not yet supported for std builds. Having this option is important for more exotic CRTs.

[danakj]

Hitting this issue in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1434719

[ChrisDenton]

Update on this: You can now use a build script (or other build method) to disable the default CRT for a binary. Then you can add back the one you want. However, you need to use a linker argument:

For the dynamic CRT use: /nodefaultlib:msvcrt
For the static CRT use: /nodefaultlib:libcmt

This can be done in a build script, for example:

fn main() {
    // Don't link the default CRT
    println!("cargo::rustc-link-arg-bins=/nodefaultlib:msvcrt")`
    // Link the debug CRT instead
    println!("cargo::rustc-link-arg-bins=/defaultlib:msvcrtd")`
}

Which isn't as nice as having a proper feature but it's at least serviceable.

[sagudev]

Update on this: You can now use a build script (or other build method) to disable the default CRT for a binary. Then you can add back the one you want. However, you need to use a linker argument:

For the dynamic CRT use: /nodefaultlib:msvcrt For the static CRT use: /nodefaultlib:libcmt

This can be done in a build script, for example:

fn main() {
// Don't link the default CRT
println!("cargo::rustc-link-arg-bins=/nodefaultlib:msvcrt") // Link the debug CRT instead println!("cargo::rustc-link-arg-bins=/defaultlib:msvcrtd")
}

Which isn't as nice as having a proper feature but it's at least serviceable.

What is MSRV for this?

[ChrisDenton]

1.79

[retep998]

Also note that if you do that, you need to make sure every C/C++ library you link against was built using the correct version of the CRT as well. If you end up mixing them then you're going to have a bad time with a lot of linker errors.