[libc++] Fixes for static libc++ on Windows using VCRuntime ABI

[andrewng]

Summary

Avoid duplicate symbol errors for std::nothrow and
std::uncaught_exception with static linking.

[andrewng]

Ping.

[andrewng]

Ping or any suggestions for other reviewers?

[andrewng]

Ping.

[ldionne]

I am not seeing any test changes or any CI configuration changes -- so is this fixing anything that libc++ can notice?

Also, one reason why this slept for so long is that the libc++ review group is not on this review. Did you follow the steps in https://libcxx.llvm.org/Contributing.html#contributing-to-libc to upload the patch (in particular arc diff)?

[andrewng]

Also, one reason why this slept for so long is that the libc++ review group is not on this review. Did you follow the steps in https://libcxx.llvm.org/Contributing.html#contributing-to-libc to upload the patch (in particular arc diff)?

I was not aware that libc++ has its own set of rules/guidelines. I will check this out and follow up as required.

I am not seeing any test changes or any CI configuration changes -- so is this fixing anything that libc++ can notice?

AFAICT, current tests and/or CI configurations are not affected. I just happened to need to test a static Windows build of LLVM with static libc++ and ran into this issue.

[andrewng]

These changes are not required. Ensuring that libc++.lib appears before msvcprt.lib solves the problem. Therefore, relying on the #pragma comment(lib, "libc++.lib") in the libc++ config doesn't really work for this Windows configuration. The libc++ testing also explicitly lists the link libraries with libc++.lib before msvcprt.lib which is why no problems are seen. However, the libc++ static test configuration does appear to be a mix of static and dynamic but that's another issue.

[mstorsjo]

In D136605#3971259, @andrewng wrote:

However, the libc++ static test configuration does appear to be a mix of static and dynamic but that's another issue.

It's not necessarily a case when _every_ library is linked statically - it's a case where libc++ itself is linked statically. Whether each of libc++, msvcp, vcruntime or UCRT are linked statically or dynamically are orthogonal distribution choices.

[andrewng]

However, the libc++ static test configuration does appear to be a mix of static and dynamic but that's another issue.

It's not necessarily a case when _every_ library is linked statically - it's a case where libc++ itself is linked statically. Whether each of libc++, msvcp, vcruntime or UCRT are linked statically or dynamically are orthogonal distribution choices.

Yes, I understand that static/dynamic isn't straightforward on Windows. In my particular configuration, libc++ was also built with the static runtime because I was trying to build LLVM with libc++ and rpmalloc enabled which requires the static runtime, i.e. -MT. So this is effectively the "fully static" configuration. Yes, there are many possible configurations although mixing dynamic and static MS runtimes is best avoided.

libcxx/src/new.cpp

#elif defined(__GLIBCXX__)
     // nothing to do
 #else
 #   include "support/runtime/new_handler_fallback.ipp"
 #endif
 
 namespace std
 {
 
-#ifndef __GLIBCXX__
+#if !defined(__GLIBCXX__) && !(defined(_LIBCPP_ABI_VCRUNTIME) && defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS))
 const nothrow_t nothrow{};
 #endif
 
 #ifndef LIBSTDCXX
 
 void
 __throw_bad_alloc()
 {

libcxx/src/support/runtime/exception_msvc.ipp

#ifndef _LIBCPP_NO_EXCEPTIONS
     {
         // handler should not throw exception
         fprintf(stderr, "terminate_handler unexpectedly threw an exception\n");
         ::abort();
     }
 #endif // _LIBCPP_NO_EXCEPTIONS
 }
 
+#if !(defined(_LIBCPP_ABI_VCRUNTIME) && defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS))
 bool uncaught_exception() noexcept { return uncaught_exceptions() > 0; }
 
 int uncaught_exceptions() noexcept {
     return __uncaught_exceptions();
 }
+#endif
 
 #if !defined(_LIBCPP_ABI_VCRUNTIME)
 bad_cast::bad_cast() noexcept
 {
 }
 
 bad_cast::~bad_cast() noexcept
 {