[libc++] Make sure we can build libc++ with -fvisibility=hidden

[ldionne]

Summary

When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.

Also, in the future, we may want to mark the whole std:: namespace as having
hidden visibility (to switch from opt-out to opt-in), in which case the
changes done in this commit will be required.

[smeenai]

It's awesome that you're looking into hidden visibility!

I'm guessing you figured out the missing symbols by running check-cxx or trying to link some applications or similar?

[ldionne]

In D52662#1249528, @smeenai wrote:

It's awesome that you're looking into hidden visibility!

The gray hair I'm growing begs to disagree :-).

I'm guessing you figured out the missing symbols by running check-cxx or trying to link some applications or similar?

I added -fvisibility=hidden to the build flags, built libc++.dylib and ran check-cxx-abilist. There were several missing symbols, and I added the annotations in this commit until there were no missing symbols anymore.

[smeenai]

In D52662#1249623, @ldionne wrote:

In D52662#1249528, @smeenai wrote:

It's awesome that you're looking into hidden visibility!

The gray hair I'm growing begs to disagree :-).

Hah, I'm sure I've lost a good amount of hair to visibility issues as well :)

I'm guessing you figured out the missing symbols by running check-cxx or trying to link some applications or similar?

I added -fvisibility=hidden to the build flags, built libc++.dylib and ran check-cxx-abilist. There were several missing symbols, and I added the annotations in this commit until there were no missing symbols anymore.

That makes sense. Back when I was looking into this (which is over a year ago now, and sadly I got pulled away into other things before I had a chance to upstream all of it), I found that only some of the missing exports when building with hidden visibility were actually required for check-cxx to pass. The rest could be added if you want to preserve ABI compatibility for v1, but hidden visibility very much seems like an ABI v2 thing, so at that point you could also fix the over-exporting.

Internally, we've been building libc++ with hidden visibility for a long time now, and it's been working well. I'm linking some of the issues from when I was working on that; I've lost all context on these by now, but I figured it might save you some trouble if you ran into similar issues:

https://bugs.llvm.org/show_bug.cgi?id=32114
https://bugs.llvm.org/show_bug.cgi?id=34614
https://github.com/smeenai/bad-visibility-finder

[ldionne]

In D52662#1249649, @smeenai wrote:

That makes sense. Back when I was looking into this (which is over a year ago now, and sadly I got pulled away into other things before I had a chance to upstream all of it), I found that only some of the missing exports when building with hidden visibility were actually required for check-cxx to pass. The rest could be added if you want to preserve ABI compatibility for v1, but hidden visibility very much seems like an ABI v2 thing, so at that point you could also fix the over-exporting.

I think this is applicable for ABI v1: those symbols are currently exported by the ABI, and it is just a coincidence that we export them from the dylib.

Internally, we've been building libc++ with hidden visibility for a long time now, and it's been working well. I'm linking some of the issues from when I was working on that; I've lost all context on these by now, but I figured it might save you some trouble if you ran into similar issues:

Why have you been building libc++ with hidden visibility? What is the advantage of doing that?

https://bugs.llvm.org/show_bug.cgi?id=32114
https://bugs.llvm.org/show_bug.cgi?id=34614
https://github.com/smeenai/bad-visibility-finder

Thanks for the links!

[smeenai]

In D52662#1249688, @ldionne wrote:

In D52662#1249649, @smeenai wrote:

That makes sense. Back when I was looking into this (which is over a year ago now, and sadly I got pulled away into other things before I had a chance to upstream all of it), I found that only some of the missing exports when building with hidden visibility were actually required for check-cxx to pass. The rest could be added if you want to preserve ABI compatibility for v1, but hidden visibility very much seems like an ABI v2 thing, so at that point you could also fix the over-exporting.

I think this is applicable for ABI v1: those symbols are currently exported by the ABI, and it is just a coincidence that we export them from the dylib.

Fair point. I think it's worth distinguishing between symbols that we actually need to export (for check-cxx or applications or similar) and symbols that just happen to be exported because of the default visibility but don't actually need to be exported. If you're already doing that in this patch, or if there aren't actually any symbols in the first category anymore, then just ignore me :)

Internally, we've been building libc++ with hidden visibility for a long time now, and it's been working well. I'm linking some of the issues from when I was working on that; I've lost all context on these by now, but I figured it might save you some trouble if you ran into similar issues:

Why have you been building libc++ with hidden visibility? What is the advantage of doing that?

For libc++, there's not too much advantage, since (a) it already controls its ABI pretty thoroughly, and (b) it already builds with -fvisibility-inlines-hidden, which takes care of a lot of cases. We did find a few symbols that were over-exported, but not enough to make any significant reductions in dynamic symbol table size. Mostly it was a cleanliness thing, where we wanted all our libraries having controlled ABIs and building with hidden visibility. It also helped us with cross-platform compatibility, since Windows always has the equivalent of hidden visibility and you have to explicitly declare your exports (which is a much nicer default IMO).

[ldionne]

In D52662#1249706, @smeenai wrote:

Fair point. I think it's worth distinguishing between symbols that we actually need to export (for check-cxx or applications or similar) and symbols that just happen to be exported because of the default visibility but don't actually need to be exported. If you're already doing that in this patch, or if there aren't actually any symbols in the first category anymore, then just ignore me :)

I'm not sure how we can ever check that a symbol is exported but not actually needed. Wouldn't this require analyzing the set of all programs linking to libc++.dylib in the wild?

Internally, we've been building libc++ with hidden visibility for a long time now, and it's been working well. I'm linking some of the issues from when I was working on that; I've lost all context on these by now, but I figured it might save you some trouble if you ran into similar issues:

Why have you been building libc++ with hidden visibility? What is the advantage of doing that?

For libc++, there's not too much advantage, since (a) it already controls its ABI pretty thoroughly, and (b) it already builds with -fvisibility-inlines-hidden, which takes care of a lot of cases. We did find a few symbols that were over-exported, but not enough to make any significant reductions in dynamic symbol table size. Mostly it was a cleanliness thing, where we wanted all our libraries having controlled ABIs and building with hidden visibility. It also helped us with cross-platform compatibility, since Windows always has the equivalent of hidden visibility and you have to explicitly declare your exports (which is a much nicer default IMO).

Got it. I agree that Windows is much saner in that respect. In the future, we could actually apply hidden visibility to all of namespace std and then only cherry-pick entities that we want to export (and apply a default-visibility attribute to those). However, that requires the ability to explicitly instantiate vtables and RTTI, which we don't have right now (but we could add as an extension to Clang). This would allow us to drop almost all of the visibility annotations we currently have in libc++.

[smeenai]

In D52662#1249753, @ldionne wrote:

In D52662#1249706, @smeenai wrote:

Fair point. I think it's worth distinguishing between symbols that we actually need to export (for check-cxx or applications or similar) and symbols that just happen to be exported because of the default visibility but don't actually need to be exported. If you're already doing that in this patch, or if there aren't actually any symbols in the first category anymore, then just ignore me :)

I'm not sure how we can ever check that a symbol is exported but not actually needed. Wouldn't this require analyzing the set of all programs linking to libc++.dylib in the wild?

Sorry, you're right. Internally I'd based my analysis on the set of symbols needed by check-clang + the set of symbols needed by all the binaries we were building (which is a pretty extensive test case), but of course that wouldn't cover everyone's use cases. There were some symbols which seemed fairly obviously internal/intended to be hidden, but since they've been part of the ABI it's entirely possible someone is using them anyway.

Internally, we've been building libc++ with hidden visibility for a long time now, and it's been working well. I'm linking some of the issues from when I was working on that; I've lost all context on these by now, but I figured it might save you some trouble if you ran into similar issues:

Why have you been building libc++ with hidden visibility? What is the advantage of doing that?

For libc++, there's not too much advantage, since (a) it already controls its ABI pretty thoroughly, and (b) it already builds with -fvisibility-inlines-hidden, which takes care of a lot of cases. We did find a few symbols that were over-exported, but not enough to make any significant reductions in dynamic symbol table size. Mostly it was a cleanliness thing, where we wanted all our libraries having controlled ABIs and building with hidden visibility. It also helped us with cross-platform compatibility, since Windows always has the equivalent of hidden visibility and you have to explicitly declare your exports (which is a much nicer default IMO).

Got it. I agree that Windows is much saner in that respect. In the future, we could actually apply hidden visibility to all of namespace std and then only cherry-pick entities that we want to export (and apply a default-visibility attribute to those). However, that requires the ability to explicitly instantiate vtables and RTTI, which we don't have right now (but we could add as an extension to Clang). This would allow us to drop almost all of the visibility annotations we currently have in libc++.

Hmm, why do we need to be able to explicitly instantiate vtables and RTTI ... doesn't the implied emission of those in the object file containing the key function work? I've been aware of a few -dev threads flying back and forth about various visibility issues for libc++, and I admit I haven't been keeping up with them fully, so I apologize if this has already been covered in one of those.

[ldionne]

In D52662#1251857, @smeenai wrote:

Hmm, why do we need to be able to explicitly instantiate vtables and RTTI ... doesn't the implied emission of those in the object file containing the key function work? I've been aware of a few -dev threads flying back and forth about various visibility issues for libc++, and I admit I haven't been keeping up with them fully, so I apologize if this has already been covered in one of those.

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

[smeenai]

In D52662#1251866, @ldionne wrote:

In D52662#1251857, @smeenai wrote:

Hmm, why do we need to be able to explicitly instantiate vtables and RTTI ... doesn't the implied emission of those in the object file containing the key function work? I've been aware of a few -dev threads flying back and forth about various visibility issues for libc++, and I admit I haven't been keeping up with them fully, so I apologize if this has already been covered in one of those.

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

Isn't that what __attribute__((type_visibility("default"))) accomplishes?

[ldionne]

In D52662#1251867, @smeenai wrote:

In D52662#1251866, @ldionne wrote:

In D52662#1251857, @smeenai wrote:

Hmm, why do we need to be able to explicitly instantiate vtables and RTTI ... doesn't the implied emission of those in the object file containing the key function work? I've been aware of a few -dev threads flying back and forth about various visibility issues for libc++, and I admit I haven't been keeping up with them fully, so I apologize if this has already been covered in one of those.

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

Isn't that what __attribute__((type_visibility("default"))) accomplishes?

The problem is that it requires applying the attribute to the class template itself as opposed to a single instantiation of it. Unless I am wrong?

Sent from iphone

[smeenai]

In D52662#1251942, @ldionne wrote:

In D52662#1251867, @smeenai wrote:

In D52662#1251866, @ldionne wrote:

In D52662#1251857, @smeenai wrote:

Hmm, why do we need to be able to explicitly instantiate vtables and RTTI ... doesn't the implied emission of those in the object file containing the key function work? I've been aware of a few -dev threads flying back and forth about various visibility issues for libc++, and I admit I haven't been keeping up with them fully, so I apologize if this has already been covered in one of those.

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

Isn't that what __attribute__((type_visibility("default"))) accomplishes?

The problem is that it requires applying the attribute to the class template itself as opposed to a single instantiation of it. Unless I am wrong?

Thinking about this more, I guess you can't really have a key function for a class template anyway, since you need to define all your methods inline for clients to be able to use your class.

[ldionne]

In D52662#1254545, @smeenai wrote:

In D52662#1251942, @ldionne wrote:

In D52662#1251867, @smeenai wrote:

In D52662#1251866, @ldionne wrote:

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

Isn't that what __attribute__((type_visibility("default"))) accomplishes?

The problem is that it requires applying the attribute to the class template itself as opposed to a single instantiation of it. Unless I am wrong?

Thinking about this more, I guess you can't really have a key function for a class template anyway, since you need to define all your methods inline for clients to be able to use your class.

You're right. I guess we _might_ be able to come up with a twisted way to achieve this with type_visibility, for example: declare (but not define) the key function in the template, then define it out-of-line, but add an explicit instantiation declaration of the key function for the specific instantiation of the class template we're interested in. And then apply the type_visibility("default") attribute to an explicit instantiation declaration of the instantiation of the class template we're interested in. IDK whether this would work, and I don't care. It's messy and too complicated, and this area of the language is already crazy enough.

[smeenai]

In D52662#1254561, @ldionne wrote:

In D52662#1254545, @smeenai wrote:

In D52662#1251942, @ldionne wrote:

In D52662#1251867, @smeenai wrote:

In D52662#1251866, @ldionne wrote:

We'd need to give default visibility to the vtable and the RTTI, which requires using an attribute.

Isn't that what __attribute__((type_visibility("default"))) accomplishes?

The problem is that it requires applying the attribute to the class template itself as opposed to a single instantiation of it. Unless I am wrong?

Thinking about this more, I guess you can't really have a key function for a class template anyway, since you need to define all your methods inline for clients to be able to use your class.

You're right. I guess we _might_ be able to come up with a twisted way to achieve this with type_visibility, for example: declare (but not define) the key function in the template, then define it out-of-line, but add an explicit instantiation declaration of the key function for the specific instantiation of the class template we're interested in. And then apply the type_visibility("default") attribute to an explicit instantiation declaration of the instantiation of the class template we're interested in. IDK whether this would work, and I don't care. It's messy and too complicated, and this area of the language is already crazy enough.

Yeah, having a direct way to instantiate the vague linkage types does seem like a much better solution :)

[EricWF]

If we're adding a new "Visibility" macro, then the VisibilityMacros.rst doc should be updated to include it.

Otherwise, I don't see any other problems in this patch. I'll leave it to other reviewers.

libcxx/include/__debug

77

Is this the only usage of _LIBCPP_EXTERN_VIS?

If so, please go ahead and purge all definitions of the macro as well as it's documentation.

[ldionne]

In D52662#1264354, @EricWF wrote:

If we're adding a new "Visibility" macro, then the VisibilityMacros.rst doc should be updated to include it.

Otherwise, I don't see any other problems in this patch. I'll leave it to other reviewers.

Done.

libcxx/include/__debug

77

Good catch, thanks!

[ldionne]

Purge _LIBCPP_EXTERN_VIS

[EricWF]

libcxx/include/locale

2426

Undef the macro after we're done using it.

libcxx/include/thread

170

So we likely only got this symbol in the dylib as a result of an implicit instantiation. Changing this to an explicit instantiation might be ABI breaking.

libcxx/src/iostream.cpp

80

Does this actually need to be exported to serve it's function of initializing the streams?

[ldionne]

Implement Eric's feedback

libcxx/include/thread

170

We agreed we could just remove the symbol. I removed the instantiation, marked the function as hidden and documented that in the ABI list CHANGELOG.

libcxx/src/iostream.cpp

80

I don't think so -- I marked it as hidden.

[ldionne]

@EricWF I think all of your concerns with this patch have been addressed -- do you see anything else or is this good to go?

[EricWF]

Yeah, this LGTM. Let's see if we break anyone!

libcxx/docs/DesignDocs/VisibilityMacros.rst

 
 **_LIBCPP_HIDDEN**
   Mark a symbol as hidden so it will not be exported from shared libraries.
 
 **_LIBCPP_FUNC_VIS**
   Mark a symbol as being exported by the libc++ library. This attribute must
   be applied to the declaration of all functions exported by the libc++ dylib.
 
-**_LIBCPP_EXTERN_VIS**
+**_LIBCPP_EXPORTED_FROM_ABI**
   Mark a symbol as being exported by the libc++ library. This attribute may
-  only be applied to objects defined in the libc++ library. On Windows this
-  macro applies `dllimport`/`dllexport` to the symbol. On all other platforms
-  this macro has no effect.
+  only be applied to objects defined in the libc++ runtime library. On Windows,
+  this macro applies `dllimport`/`dllexport` to the symbol, and on other
+  platforms it gives the symbol default visibility.
 
 **_LIBCPP_OVERRIDABLE_FUNC_VIS**
   Mark a symbol as being exported by the libc++ library, but allow it to be
   overridden locally. On non-Windows, this is equivalent to `_LIBCPP_FUNC_VIS`.
   This macro is applied to all `operator new` and `operator delete` overloads.
 
   **Windows Behavior**: Any symbol marked `dllimport` cannot be overridden
   locally, since `dllimport` indicates the symbol should be bound to a separate

libcxx/include/__config

 #  define _LIBCPP_CRT_FUNC
 #endif
 
 #if defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #  define _LIBCPP_DLL_VIS
 #  define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
 #  define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
 #  define _LIBCPP_OVERRIDABLE_FUNC_VIS
+#  define _LIBCPP_EXPORTED_FROM_ABI
 #elif defined(_LIBCPP_BUILDING_LIBRARY)
 #  define _LIBCPP_DLL_VIS __declspec(dllexport)
 #  define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
 #  define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS _LIBCPP_DLL_VIS
 #  define _LIBCPP_OVERRIDABLE_FUNC_VIS _LIBCPP_DLL_VIS
+#  define _LIBCPP_EXPORTED_FROM_ABI __declspec(dllexport)
 #else
 #  define _LIBCPP_DLL_VIS __declspec(dllimport)
 #  define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
 #  define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
 #  define _LIBCPP_OVERRIDABLE_FUNC_VIS
+#  define _LIBCPP_EXPORTED_FROM_ABI __declspec(dllimport)
 #endif
 
 #define _LIBCPP_TYPE_VIS            _LIBCPP_DLL_VIS
 #define _LIBCPP_FUNC_VIS            _LIBCPP_DLL_VIS
-#define _LIBCPP_EXTERN_VIS          _LIBCPP_DLL_VIS
 #define _LIBCPP_EXCEPTION_ABI       _LIBCPP_DLL_VIS
 #define _LIBCPP_HIDDEN
 #define _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
 #define _LIBCPP_TEMPLATE_VIS
 #define _LIBCPP_ENUM_VIS
 
 #endif // defined(_LIBCPP_OBJECT_FORMAT_COFF)
 

 #    else
 #      define _LIBCPP_TEMPLATE_VIS __attribute__ ((__visibility__("default")))
 #    endif
 #  else
 #    define _LIBCPP_TEMPLATE_VIS
 #  endif
 #endif
 
-#ifndef _LIBCPP_EXTERN_VIS
-#define _LIBCPP_EXTERN_VIS
+#ifndef _LIBCPP_EXPORTED_FROM_ABI
+#  define _LIBCPP_EXPORTED_FROM_ABI __attribute__((__visibility__("default")))
 #endif
 
 #ifndef _LIBCPP_OVERRIDABLE_FUNC_VIS
 #define _LIBCPP_OVERRIDABLE_FUNC_VIS _LIBCPP_FUNC_VIS
 #endif
 
 #ifndef _LIBCPP_EXCEPTION_ABI
 #  if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)

libcxx/include/__debug

struct _LIBCPP_TEMPLATE_VIS __libcpp_debug_info {
   const char* __msg_;
 };
 
 /// __libcpp_debug_function_type - The type of the assertion failure handler.
 typedef void(*__libcpp_debug_function_type)(__libcpp_debug_info const&);
 
 /// __libcpp_debug_function - The handler function called when a _LIBCPP_ASSERT
 ///    fails.
-extern _LIBCPP_EXTERN_VIS __libcpp_debug_function_type __libcpp_debug_function;
+extern _LIBCPP_EXPORTED_FROM_ABI __libcpp_debug_function_type __libcpp_debug_function;
 
 /// __libcpp_abort_debug_function - A debug handler that aborts when called.
 _LIBCPP_NORETURN _LIBCPP_FUNC_VIS
 void __libcpp_abort_debug_function(__libcpp_debug_info const&);
 
 /// __libcpp_throw_debug_function - A debug handler that throws
 ///   an instance of __libcpp_debug_exception when called.
  _LIBCPP_NORETURN _LIBCPP_FUNC_VIS

libcxx/include/__functional_base

struct __is_transparent<_Tp, _Up,
    : true_type {};
 #endif
 
 // allocator_arg_t
 
 struct _LIBCPP_TEMPLATE_VIS allocator_arg_t { };
 
 #if defined(_LIBCPP_CXX03_LANG) || defined(_LIBCPP_BUILDING_LIBRARY)
-extern const allocator_arg_t allocator_arg;
+extern _LIBCPP_EXPORTED_FROM_ABI const allocator_arg_t allocator_arg;
 #else
 /* _LIBCPP_INLINE_VAR */ constexpr allocator_arg_t allocator_arg = allocator_arg_t();
 #endif
 
 // uses_allocator
 
 template <class _Tp>
 struct __has_allocator_type

libcxx/include/__locale

struct __narrow_to_utf8<8>
     {
         for (; __wb < __we; ++__wb, ++__s)
             *__s = *__wb;
         return __s;
     }
 };
 
 template <>
-struct __narrow_to_utf8<16>
+struct _LIBCPP_TEMPLATE_VIS __narrow_to_utf8<16>
     : public codecvt<char16_t, char, mbstate_t>
 {
     _LIBCPP_INLINE_VISIBILITY
     __narrow_to_utf8() : codecvt<char16_t, char, mbstate_t>(1) {}
 
-    ~__narrow_to_utf8();
+    _LIBCPP_EXPORTED_FROM_ABI ~__narrow_to_utf8();
 
     template <class _OutputIterator, class _CharT>
     _LIBCPP_INLINE_VISIBILITY
     _OutputIterator
     operator()(_OutputIterator __s, const _CharT* __wb, const _CharT* __we) const
     {
         result __r = ok;
         mbstate_t __mb;
operator()(_OutputIterator __s, const _CharT* __wb, const _CharT* __we) const
                 *__s = *__p;
             __wb = (const _CharT*)__wn;
         }
         return __s;
     }
 };
 
 template <>
-struct __narrow_to_utf8<32>
+struct _LIBCPP_TEMPLATE_VIS __narrow_to_utf8<32>
     : public codecvt<char32_t, char, mbstate_t>
 {
     _LIBCPP_INLINE_VISIBILITY
     __narrow_to_utf8() : codecvt<char32_t, char, mbstate_t>(1) {}
 
-    ~__narrow_to_utf8();
+    _LIBCPP_EXPORTED_FROM_ABI ~__narrow_to_utf8();
 
     template <class _OutputIterator, class _CharT>
     _LIBCPP_INLINE_VISIBILITY
     _OutputIterator
     operator()(_OutputIterator __s, const _CharT* __wb, const _CharT* __we) const
     {
         result __r = ok;
         mbstate_t __mb;
struct __widen_from_utf8<8>
     {
         for (; __nb < __ne; ++__nb, ++__s)
             *__s = *__nb;
         return __s;
     }
 };
 
 template <>
-struct __widen_from_utf8<16>
+struct _LIBCPP_TEMPLATE_VIS __widen_from_utf8<16>
     : public codecvt<char16_t, char, mbstate_t>
 {
     _LIBCPP_INLINE_VISIBILITY
     __widen_from_utf8() : codecvt<char16_t, char, mbstate_t>(1) {}
 
-    ~__widen_from_utf8();
+    _LIBCPP_EXPORTED_FROM_ABI ~__widen_from_utf8();
 
     template <class _OutputIterator>
     _LIBCPP_INLINE_VISIBILITY
     _OutputIterator
     operator()(_OutputIterator __s, const char* __nb, const char* __ne) const
     {
         result __r = ok;
         mbstate_t __mb;
operator()(_OutputIterator __s, const char* __nb, const char* __ne) const
                 *__s = (wchar_t)*__p;
             __nb = __nn;
         }
         return __s;
     }
 };
 
 template <>
-struct __widen_from_utf8<32>
+struct _LIBCPP_TEMPLATE_VIS __widen_from_utf8<32>
     : public codecvt<char32_t, char, mbstate_t>
 {
     _LIBCPP_INLINE_VISIBILITY
     __widen_from_utf8() : codecvt<char32_t, char, mbstate_t>(1) {}
 
-    ~__widen_from_utf8();
+    _LIBCPP_EXPORTED_FROM_ABI ~__widen_from_utf8();
 
     template <class _OutputIterator>
     _LIBCPP_INLINE_VISIBILITY
     _OutputIterator
     operator()(_OutputIterator __s, const char* __nb, const char* __ne) const
     {
         result __r = ok;
         mbstate_t __mb;

libcxx/include/__mutex_base

static_assert(is_nothrow_default_constructible<mutex>::value,
               "the default constructor for std::mutex must be nothrow");
 
 struct _LIBCPP_TYPE_VIS defer_lock_t {};
 struct _LIBCPP_TYPE_VIS try_to_lock_t {};
 struct _LIBCPP_TYPE_VIS adopt_lock_t {};
 
 #if defined(_LIBCPP_CXX03_LANG) || defined(_LIBCPP_BUILDING_LIBRARY)
 
-extern const defer_lock_t  defer_lock;
-extern const try_to_lock_t try_to_lock;
-extern const adopt_lock_t  adopt_lock;
+extern _LIBCPP_EXPORTED_FROM_ABI const defer_lock_t  defer_lock;
+extern _LIBCPP_EXPORTED_FROM_ABI const try_to_lock_t try_to_lock;
+extern _LIBCPP_EXPORTED_FROM_ABI const adopt_lock_t  adopt_lock;
 
 #else
 
 /* _LIBCPP_INLINE_VAR */ constexpr defer_lock_t  defer_lock  = defer_lock_t();
 /* _LIBCPP_INLINE_VAR */ constexpr try_to_lock_t try_to_lock = try_to_lock_t();
 /* _LIBCPP_INLINE_VAR */ constexpr adopt_lock_t  adopt_lock  = adopt_lock_t();
 
 #endif

libcxx/include/charconv

 #include <__debug>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
+namespace __itoa {
+_LIBCPP_FUNC_VIS char* __u64toa(uint64_t __value, char* __buffer);
+_LIBCPP_FUNC_VIS char* __u32toa(uint32_t __value, char* __buffer);
+}
+
 #if _LIBCPP_STD_VER > 11
 
 enum class _LIBCPP_ENUM_VIS chars_format
 {
     scientific = 0x1,
     fixed = 0x2,
     hex = 0x4,
     general = fixed | scientific

 
 static constexpr uint32_t __pow10_32[] = {
     UINT32_C(0),          UINT32_C(10),       UINT32_C(100),
     UINT32_C(1000),       UINT32_C(10000),    UINT32_C(100000),
     UINT32_C(1000000),    UINT32_C(10000000), UINT32_C(100000000),
     UINT32_C(1000000000),
 };
 
-_LIBCPP_FUNC_VIS char* __u64toa(uint64_t __value, char* __buffer);
-_LIBCPP_FUNC_VIS char* __u32toa(uint32_t __value, char* __buffer);
-
 template <typename _Tp, typename = void>
 struct _LIBCPP_HIDDEN __traits_base
 {
     using type = uint64_t;
 
 #if !defined(_LIBCPP_COMPILER_MSVC)
     static _LIBCPP_INLINE_VISIBILITY int __width(_Tp __v)
     {

libcxx/include/locale

protected:
 
     time_base::dateorder __do_date_order() const;
 
 private:
     void init(const ctype<_CharT>&);
     string_type __analyze(char __fmt, const ctype<_CharT>&);
 };
 
+#define _LIBCPP_TIME_GET_STORAGE_EXPLICIT_INSTANTIATION(_CharT) \
+template <> _LIBCPP_FUNC_VIS time_base::dateorder __time_get_storage<_CharT>::__do_date_order() const; \
+template <> _LIBCPP_FUNC_VIS __time_get_storage<_CharT>::__time_get_storage(const char*); \
+template <> _LIBCPP_FUNC_VIS __time_get_storage<_CharT>::__time_get_storage(const string&); \
+template <> _LIBCPP_FUNC_VIS void __time_get_storage<_CharT>::init(const ctype<_CharT>&); \
+template <> _LIBCPP_FUNC_VIS __time_get_storage<_CharT>::string_type __time_get_storage<_CharT>::__analyze(char, const ctype<_CharT>&); \
+extern template _LIBCPP_FUNC_VIS time_base::dateorder __time_get_storage<_CharT>::__do_date_order() const; \
+extern template _LIBCPP_FUNC_VIS __time_get_storage<_CharT>::__time_get_storage(const char*); \
+extern template _LIBCPP_FUNC_VIS __time_get_storage<_CharT>::__time_get_storage(const string&); \
+extern template _LIBCPP_FUNC_VIS void __time_get_storage<_CharT>::init(const ctype<_CharT>&); \
+extern template _LIBCPP_FUNC_VIS __time_get_storage<_CharT>::string_type __time_get_storage<_CharT>::__analyze(char, const ctype<_CharT>&); \
+/**/
+
+_LIBCPP_TIME_GET_STORAGE_EXPLICIT_INSTANTIATION(char)
+_LIBCPP_TIME_GET_STORAGE_EXPLICIT_INSTANTIATION(wchar_t)
+
 template <class _CharT, class _InputIterator = istreambuf_iterator<_CharT> >
 class _LIBCPP_TEMPLATE_VIS time_get_byname
     : public time_get<_CharT, _InputIterator>,
       private __time_get_storage<_CharT>
 {
 public:
     typedef time_base::dateorder    dateorder;
     typedef _InputIterator          iter_type;

libcxx/include/thread

public:
     pointer get() const {return static_cast<_Tp*>(__libcpp_tls_get(__key_));}
     _LIBCPP_INLINE_VISIBILITY
     pointer operator*() const {return *get();}
     _LIBCPP_INLINE_VISIBILITY
     pointer operator->() const {return get();}
     void set_pointer(pointer __p);
 };
 
+extern template _LIBCPP_EXPORTED_FROM_ABI void __thread_specific_ptr<__thread_struct>::__at_thread_exit(void*);
+
 template <class _Tp>
 void _LIBCPP_TLS_DESTRUCTOR_CC
 __thread_specific_ptr<_Tp>::__at_thread_exit(void* __p)
 {
     delete static_cast<pointer>(__p);
 }
 
 template <class _Tp>

libcxx/include/utility

 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp> constexpr add_const_t<_Tp>& as_const(_Tp& __t) noexcept { return __t; }
 template <class _Tp>                        void as_const(const _Tp&&) = delete;
 #endif
 
 struct _LIBCPP_TEMPLATE_VIS piecewise_construct_t { };
 #if defined(_LIBCPP_CXX03_LANG) || defined(_LIBCPP_BUILDING_LIBRARY)
-extern const piecewise_construct_t piecewise_construct;// = piecewise_construct_t();
+extern _LIBCPP_EXPORTED_FROM_ABI const piecewise_construct_t piecewise_construct;// = piecewise_construct_t();
 #else
 /* _LIBCPP_INLINE_VAR */ constexpr piecewise_construct_t piecewise_construct = piecewise_construct_t();
 #endif
 
 #if defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 struct __non_trivially_copyable_base {
   _LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
   __non_trivially_copyable_base() _NOEXCEPT {}

libcxx/lib/CMakeLists.txt

 if(NOT LIBCXX_INSTALL_LIBRARY)
   set(exclude_from_all EXCLUDE_FROM_ALL)
 endif()
 
 # If LIBCXX_CXX_ABI_LIBRARY_PATH is defined we want to add it to the search path.
 add_link_flags_if(LIBCXX_CXX_ABI_LIBRARY_PATH
                   "${CMAKE_LIBRARY_PATH_FLAG}${LIBCXX_CXX_ABI_LIBRARY_PATH}")
 
-
 if (LIBCXX_GENERATE_COVERAGE AND NOT LIBCXX_COVERAGE_LIBRARY)
   find_compiler_rt_library(profile LIBCXX_COVERAGE_LIBRARY)
 endif()
 add_library_flags_if(LIBCXX_COVERAGE_LIBRARY "${LIBCXX_COVERAGE_LIBRARY}")
 
 if (APPLE AND (LIBCXX_CXX_ABI_LIBNAME STREQUAL "libcxxabi" OR
                LIBCXX_CXX_ABI_LIBNAME STREQUAL "default"))
   set(LIBCXX_OSX_REEXPORT_SYSTEM_ABI_LIBRARY ON)

libcxx/src/iostream.cpp

 #endif
 ;
 _ALIGNAS_TYPE (wostream) _LIBCPP_FUNC_VIS char wclog[sizeof(wostream)]
 #if defined(_LIBCPP_ABI_MICROSOFT) && defined(__clang__)
 __asm__("?wclog@" _LIBCPP_NAMESPACE_STR "@std@@3V?$basic_ostream@_WU?$char_traits@_W@" _LIBCPP_NAMESPACE_STR "@std@@@12@A")
 #endif
 ;
 
-ios_base::Init __start_std_streams;
+_LIBCPP_EXPORTED_FROM_ABI ios_base::Init __start_std_streams;
 
 ios_base::Init::Init()
 {
 #ifndef _LIBCPP_HAS_NO_STDIN
     istream* cin_ptr  = ::new(cin)  istream(::new(__cin)  __stdinbuf <char>(stdin, &mb_cin));
     wistream* wcin_ptr  = ::new(wcin)  wistream(::new(__wcin)  __stdinbuf <wchar_t>(stdin, &mb_wcin));
 #endif
 #ifndef _LIBCPP_HAS_NO_STDOUT

libcxx/src/thread.cpp

sleep_for(const chrono::nanoseconds& ns)
     if (ns > chrono::nanoseconds::zero())
     {
         __libcpp_thread_sleep_for(ns);
     }
 }
 
 }  // this_thread
 
+template void __thread_specific_ptr<__thread_struct>::__at_thread_exit(void*);
+
 __thread_specific_ptr<__thread_struct>&
 __thread_local_data()
 {
     static __thread_specific_ptr<__thread_struct> __p;
     return __p;
 }
 
 // __thread_struct_imp