[cfe-dev] [RFC][libcxx] Fixing "-stdlib=libc++ -lc++abi" on Linux -- Exporting libc++abi through libc++.so.

[Saleem Abdulrasool via cfe-dev]

On Sun, Oct 11, 2015 at 4:58 PM, Eric Fiselier via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi All,
>
> As many of you know libc++ doesn't build correctly on Linux by
> default. In particular the resulting library cannot be used with
> "-stdlib=libc++" alone. This forces the user to manually link the
> correct ABI library, usually by adding '-lc++abi' whenever they link a
> program or library.
>
> We need to fix the default libc++ build configuration so that
> libc++.so just works. This fix cannot be done in clang. libc++
> supports using 3+ different ABI libraries and even more ways to link
> them. It's not feasible for clang to know how libc++ was built and
> trying to teach it would limit the flexibility libc++ already has.
>
> I would like to propose a solution to fix the default build
> configuration. For simplicity I will explain it using libc++abi as the
> example but any supported library will work.
>
> Solution: Libc++ should use a linker script for libc++.so as opposed
> to a symlink.
> (See http://reviews.llvm.org/D12508)
>
> The linker script would contain "INPUT(libc++.1.so -lc++abi)". This
> instructs the linker to include libc++.1.so as if it were this file
> and add '-lc++abi' to the link command. Currently libc++.so is a
> symlink to libc++.so.1.
>
> The most important part of this approach is that it allows us to use a
> shared libc++abi.
> We want to avoid using a static library because libc++abi contains
> symbols which have to be unique within a process. These symbols
> include exception handling globals, RTTI support, and definitions for
> standard library exceptions. By keeping these symbols out of libc++ we
> can allow different libc++ versions and even different standard
> library implementations to coexist peacefully in the same process as
> long as they share the same libc++abi.
>

I don't believe I understand why libc++abi cannot be statically linked into
libc++.  (As an aside, this is how libstdc++ gets away with it).

Statically linking the ABI into the c++ library would ensure that the same
ABI is always used, it would be unique across the process still, and would
not impede using alternative ABI providers.  Obviously, this comes at the
slight cost of increasing the size of libc++, though both libraries would
need to be loaded always.  The other "downside" is that you cannot update
the ABI provider without rebuilding all of libc++.  However, this is a
feature as well: you are certain that the ABI provider doesn't change (yes,
libc++abi is pretty stable, but hypothetically, we may fix UB -- like the
one with alignment of allocations done in libc++abi).

Doing this also has the added benefit of being much less Linux centric and
would allow us to use the same mechanism even on Windows with link.exe
(although, ld.bfd permits the use of linker scripts on windows).

I think that if the same ABI provider was used across multiple versions,
they could continue to coexist even if statically linked.

This approach is how FreeBSD ships their systems libc++. OS X take a
> slightly different approach which uses also uses a shared ABI library.
> It works by re-exporting libc++abi's symbols into libc++.dylib at
> build time using the "-reexported_symbols_list" linker flag.
>
> Questions:
>
> 1. What Linux linkers, if any, don't support linker scripts? Does lld?
> 2. Would installing libc++.so as a linker script cause problems with
> ldconfig?
> 3. Does LD provide any way to reexport symbols lists comparable to how
> "-reexported_symbols_list" on OS X?
>
>
> I would love any and all input on this plan. Please correct me if I've
> gotten any details wrong.
> If nobody objects I would like to quickly move forward with this.

/Eric
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151011/40ccaade/attachment.html>