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

[Eric Fiselier via cfe-dev]

Hi Saleem,

Thanks for the response.

> 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.

I was originally under the impression that this would prevent multiple
libc++ versions from existing in the same executable because they would
each contain a different copy of the libc++abi symbols.
Am I incorrect in this assertion?

I also don't see how using a linker script would impede using alternative
ABI providers. The script could be tailored to support any of them.

>  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).

This is a major downside for libc++abi developers if we make this the
default behavior. I also don't think people expect perfect ABI stability
when building a ToT release of libc++. I agree with both your points but I
don't think they are reasons to use this configuration as the default
configuration.

/Eric


On Mon, Oct 12, 2015 at 5:19 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 12 Oct 2015, at 00:58, Eric Fiselier via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >
> > 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.
>
> This is how FreeBSD ships libc++ (except that we use libcxxrt, not
> libc++abi), but it will cause problems on Linux unless you *also* change
> the way that libstdc++ is shipped.
>
> Libstdc++ statically links libsupc++ (the GNU equivalent of libcxxrt /
> libc++abi) and this has an impact on symbol versioning.  If something links
> to both libstdc++ with libsupc++ and libc++ with libc++abi then the ABI
> symbols will be distinct.  Throwing an exception in code using one and
> catching it in the other will break in difficult-to-diagnose ways.
>
> We addressed this by linking libstdc++ as a filter library against
> libsupc++ then against libcxxrt.  Libraries linking libstdc++ see the ABI
> symbols as having come from libstdc++, when in reality they are provided by
> libcxxrt.  This allows interoperability.
>
> If you can not modify the linkage of libstdc++ on your target platform,
> then the best solution is to use libstdc++ itself as the ABI library.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151013/31262b33/attachment.html>