This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question on DSO and visibility


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]