[cfe-dev] Statically linking libc++/libc++abi (ELF)

[Matt Glazar via cfe-dev]

I want to statically link libc++ and libc++abi into my ELF DSO (shared
library). (Statically linking avoids incompatibilities with other
libc++/libstdc++/etc. loaded at runtime by other DSO-s.) (My DSO exports
no C++ APIs, imports no C++ APIs, does not throw or catch exceptions
across DSO boundaries, does not require callers to delete returned
pointers, etc.)

To achieve this, I am using -fvisibility=hidden,
-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS, and
-D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS (and some other tweaks) when
compiling libc++, libc++abi, and my own code. I build libc++ and libc++abi
as static libraries and link them into my DSO.

This seems to work well. However, Clang forces some libc++abi symbols to
default visibility. This puts these symbols in my DSO's dynamic export
table. Thus:

* Linking against my DSO may inadvertently use my DSO's symbols instead of
the symbols you expect (e.g. the system libstdc++'s symbols).
* It also means my DSO's references to its libc++abi symbols may be
replaced at runtime with another DSO's symbols (e.g. the system
libstdc++'s symbols).

From what I have found so far, default visibility for libc++abi symbols is
forced in two places in Clang:

* lib/Sema/SemaExprCXX.cpp Sema::DeclareGlobalAllocationFunction
* lib/CodeGen/ItaniumCXXABI.cpp ItaniumRTTIBuilder::BuildTypeInfo

Is there a reason these symbols *must* have default visibility? I
understand that, in general, typeinfo should have default visibility for
exception handling to function properly. Does an opt-in option to change
the visibility of these symbols (for use cases like mine) sound reasonable?

Thanks,

Matthew Glazar