[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

Shoaib Meenai via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 13 22:12:21 PST 2017

smeenai added inline comments.

Comment at: lib/CMakeLists.txt:112
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)
EricWF wrote:
> smeenai wrote:
> > EricWF wrote:
> > > halyavin wrote:
> > > > halyavin wrote:
> > > > > As far as I know, applications shouldn't use msvcrt.dll ([[ https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 | Windows is not a Microsoft Visual C/C++ Run-Time delivery channel ]]) Can we survive on ucrt only?
> > > > Oh, it is static library that doesn't correspond to a dll.
> > > I don't think that link suggests that applications shouldn't link `msvcrt.dll`. 
> > > 
> > > Instead all of the doc I see suggests that `msvcrt.dll` is linked implicitly by `/MD`. However since libc++ removes `/MD` and adds `/nodefaultlibs` we need to manually re-create the `/MD` link without the MSVC STL. That involves manually linking `msvcrt.dll`.
> > There's a distinction between `msvcrt.lib` and `msvcrt.dll`. `msvcrt.lib` is a static library which contains the entry point (`_DllMainCRTStartup at 12`, etc.). It's basically the equivalent of crtbegin for Windows. `msvcrt.dll` is the unversioned legacy version of the C runtime, which is what you're not supposed to use. It's kinda confusing since the normal convention is for `X.lib` to be the import library corresponding to `X.dll`, but that's not the case for `msvcrt`.
> `msvcrt.dll` doesn't exist anymore according to [this](https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx)
It's not documented anymore (because they don't want you using it), but you can find it in `C:\Windows\system32`, and MinGW still linked against it, the last time I checked.


More information about the cfe-commits mailing list