[libcxx-commits] [PATCH] D90021: [libcxx] [libcxxabi] Set flags for visibility when statically linking libcxxabi into libcxx for windows

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
Comment at: libcxx/CMakeLists.txt:874
+    # instead of dllimport.
+    add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
+  elseif(LIBCXX_ENABLE_STATIC AND LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY)
----------------
mstorsjo wrote:
> ldionne wrote:
> > Why does `_LIBCXXABI_BUILDING_LIBRARY` have an impact when building libc++?
> In practice, `_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS` works essentially the same. If there's inline definitions in headers that would need to be exported, I think `_LIBCXXABI_BUILDING_LIBRARY` would be a bit more consistent (as the statically linked libcxxabi would essentially be a part of the final libc++ DLL), but I'm not sure it matters.
Phrasing it differently: If nothing is defined, any reference to symbols provided by libcxxabi, in code generated within libcxx, is generated as if it is going to be imported from a different DLL. If `_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS` is defined, the references are as if the code is going to be within the same DLL (which is true). 

If `_LIBCXXABI_BUILDING_LIBRARY` is defined, any reference to the symbols are as if they are in the same DLL (same as with `_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS`), but any time such a symbol is defined (which only would happen for inline functions in headers), it also generates an annotation in the object file, saying that this particular symbol should be exported out from the DLL.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90021/new/

https://reviews.llvm.org/D90021