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

[James Y Knight via cfe-dev]

Typically the way people do this is by passing a --version-script to the
linker, which lets you include/exclude symbols as you wish regardless of
the visibility attributes.

Even more so when building against libstdc++ headers, which forces nearly
everything to have default visibility, no matter what.

On Wed, Jan 4, 2017 at 4:21 PM, Matt Glazar via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170104/fd03f243/attachment.html>