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

[Eric Fiselier via cfe-dev]

Hi David,

Thanks for taking the time to respond.

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

Obviously I have no power to modify the linkage of libstdc++ in general.
However I don't think using libstdc++ as the ABI library is the best
default for libc++.
I understand it is needed in order to support inter-operability but for
obvious reasons I think libc++abi is the correct default to use out of the
box.

However the idea of using a linker script as libc++.so will also fix the
case where libstdc++.so is actually used.
When the user builds against libstdc++ the linker script will contain
"INPUT(libc++.so.1 -lstdc++)".

/Eric

On Tue, Oct 13, 2015 at 3:43 PM, Eric Fiselier <eric at efcs.ca> wrote:

> 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/c7779530/attachment.html>