For -windows-msvc targets linking the C runtime (e.g. C main, etc) is done in the libc crate which then hard codes the CRT startup libraries to use, which means they can't be overridden (without hacks or no_std) except to choose between dynamic or static linking. This makes it difficult to select the right CRT for certain builds. This matters particularly when integrating Rust alongside existing C/C++ build systems. The same CRT must be used in all cases.
I would propose that rustc should behave more like cl (the MSVC compiler) in this case. We should use /DEFAULTLIB: to link the CRT so the library is overridable rather than hard coded. This also means it can work with existing tools rather than needing anything custom for rustc.
For
-windows-msvctargets linking the C runtime (e.g. C main, etc) is done in thelibccrate which then hard codes the CRT startup libraries to use, which means they can't be overridden (without hacks orno_std) except to choose between dynamic or static linking. This makes it difficult to select the right CRT for certain builds. This matters particularly when integrating Rust alongside existing C/C++ build systems. The same CRT must be used in all cases.I would propose that
rustcshould behave more likecl(the MSVC compiler) in this case. We should use/DEFAULTLIB:to link the CRT so the library is overridable rather than hard coded. This also means it can work with existing tools rather than needing anything custom forrustc.