This is the mail archive of the
mailing list for the GCC project.
Re: Question on DSO and visibility
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paul Smith <paul at mad-scientist dot net>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 14 Sep 2016 16:26:36 +0100
- Subject: Re: Question on DSO and visibility
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <CAH6eHdTmQUgXwQvi99JsCnALJioeBp=KDJFY2Zb+NFLZw16LRQ@mail.gmail.com> <firstname.lastname@example.org>
On 14 September 2016 at 15:26, Paul Smith wrote:
> On Wed, 2016-09-14 at 10:13 +0100, Jonathan Wakely wrote:
>> The real problem is that your library will depend on a newer libstdc++
>> but that's orthogonal to the ABI changes. Statically linking it is one
>> solution, deploying the newer libstdc++.so with your library is
> Yes, again good point. So, as long as I don't pass objects of the
> problematic types across the ABI all is fine assuming a sufficient
> libstd++ library is available.
Right. If making the new libstdc++.so available is a problem then your
static linking + -fvisibility=hidden approach should work. I think :-)
> There's one question: what about exceptions? std::exception::what()
> returns a const char*; I don't know if that's stored internally as a
> std::string which might have problematic types. If I throw an exception
> from my code (new GCC/ABI) and it's caught by the caller's code (old
> GCC/ABI) is there a problem? I'm assuming this is not an issue.
The exception classes are the same in the old and new ABIs (except for
std::ios_base::failure, which gains a new base class and data members
in C++11, so had to change anyway). The character data returned by
what() is always stored in a copy-on-write string, even when
std::string is the non-copy-on-write std::__cxx11::string.