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

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added inline comments.


================
Comment at: lib/CMakeLists.txt:108-109
+if (LIBCXX_TARGETING_WINDOWS)
+  add_compile_flags(/Zl)
+  add_link_flags(/nodefaultlib)
+  add_library_flags(ucrt) # Universal C runtime
----------------
halyavin wrote:
> smeenai wrote:
> > These should be guarded under a check for a cl or cl-like frontend rather than `LIBCXX_TARGETING_WINDOWS` (since in theory we could be using the regular clang frontend to compile for Windows as well).
> Regular clang supports both gcc-like and cl-like options (there are 2 compilers: clang.exe and clang-cl.exe). I think it is not worth it to support both considering they differ only in command line options handling.
I'm aware of the separate drivers, but I still think it's worthwhile specifying appropriate conditionals when it's easy enough to do. (In this case, the inverse check of https://reviews.llvm.org/diffusion/L/browse/libcxx/trunk/CMakeLists.txt;291339$394 should do the trick.)


================
Comment at: lib/CMakeLists.txt:111
+  add_library_flags(ucrt) # Universal C runtime
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files
----------------
halyavin wrote:
> smeenai wrote:
> > Idk if there's anything specific to C++ in vcruntime; it's more compiler runtime functions as far as I know.
> It contains exception handling stuff.
You're right, but it also contains `longjmp`, `memcpy`, `memmove`, `memset`, etc, which is why I found the comment slightly weird initially. I guess it's fairly accurate as far as the usage of vcruntime in libc++ goes though.


https://reviews.llvm.org/D28441