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.
