clang,windows: why doesn't -fms-runtime-lib=dll implicitly pass -Wl,/NODEFAULTLIB:libcmt?

[AlexRouSg]

While trying to build a project that uses msvc built glfw which uses the dll runtime,
there are linker errors relating to conflicting runtimes. So the obvious thing to do would be to add /MD or the clang eq of -fms-runtime-lib=dll.

But apparently that doesn't set -Wl,/NODEFAULTLIB:libcmt which was not obvious was the problem as the warning only ever say

LINK : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

So seems rather odd to have to say "use the dll runtime" and "don't use the static runtime" at the same time and wonder if there is a situation where someone would want that or is it something that could be implicitly set?

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Chotepud Teo (AlexRouSg)

While trying to build a project that uses msvc built glfw which uses the dll runtime, there are linker errors relating to conflicting runtimes. So the obvious thing to do would be to add `/MD` or the clang eq of `-fms-runtime-lib=dll`.

But apparently that doesn't set -Wl,/NODEFAULTLIB:libcmt which was not obvious was the problem as the warning only ever say
> LINK : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

So seems rather odd to have to say "use the dll runtime" and "don't use the static runtime" at the same time and wonder if there is a situation where someone would want that or is it something that could be implicitly set?

[lyj-514328]

I think this might be a bug in clang-driver, as for linker.exe, clang always passes "-defaultlib:libcmt" "-defaultlib:oldnames".

"C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\bin\\Hostx64\\x64\\link.exe" "-out:a.exe" "-defaultlib:libcmt" "-defaultlib:oldnames" "-libpath:C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\lib\\x64" "-libpath:C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\atlmfc\\lib\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.26100.0\\ucrt\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.26100.0\\um\\x64" "-libpath:C:\\Users\\yijli\\Downloads\\clang+llvm-20.1.7-x86_64-pc-windows-msvc\\lib\\clang\\20\\lib\\windows" "-nologo" "C:\\Users\\yijli\\AppData\\Local\\Temp\\a-130864.o"

However, clang-cl and flang don't seem to have this issue, so it's unclear whether this is a feature or a bug.

[tru]

I think this is probably a bug. Most likely because this is not a common use case to call clang for linking on windows. Most build systems on windows call lld-link directly and don't use the clang driver to invoke it.

Would happily approve a PR that fixed this, just know you are on a path that's seldom walked.

[AlexRouSg]

I would try to look into it but I am too unfamiliar with LLVM to even know what repo and file to look at.
But for those that want to try, would the fix be to pass -Wl,/NODEFAULTLIB:libcmt or would the fix be to not blindly pass -defaultlib:libcmt -defaultlib:oldnames or both?

[tru]

It happens here

llvm-project/clang/lib/Driver/ToolChains/MSVC.cpp

Line 63 in 84d65e9

void visualstudio::Linker::ConstructJob(Compilation &C, const JobAction &JA,

I would probably just elide the defaultlib things when the -md option is passed.