GCC compatibility of shared libraries with STL objects in their interface

Jonathan Wakely jwakely.gcc@gmail.com
Mon Nov 30 00:23:00 GMT 2015


On 29 November 2015 at 21:19, Robert Fanner wrote:
> So, I'm curious about what the case will be with respect to the STL
> classes used as part of the plug-in interface. Can I safely pass STL
> objects between shared objects that weren't compiled with the same
> compiler version (e.g. 4.1 and 4.8)? And is there anything I need to
> be mindful of with regards to how templates are compiled and resolved
> if people use different compiler options?

In general no, but it depends which options you're talking about.

If you use -fshort-wchar then you change the ABI, but if you do that
then libstdc++.so won't work properly unless you recompile it anyway.
Barring ABI-changing options, the library ABI is stable. It doesn't
matter whether you use it internally to a DSO or in the interface, the
library ABI is stable.


> I suspect it'll be problematic. However, there's a chance the symbol
> versioning magic done by the GCC folks might somehow make this work.

The library ABI is stable and so everything should be fully backwards
compatible.

The only real caveat is that GCC 5.1 introduced a new ABI for some
types (std::list and std::string and anything that depends on
std::string), but the old ABI is still fully supported and present in
the DSO, so objects compiled with GCC 4.x still work with the
libstdc++.so from GCC 5.x, see
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
for more details.

> For this question, I am only interested in pre-C++11 compilation and
> linking. I am also only interested in Linux and Mac OS X, using GCC.

In general C++11 doesn't change anything, the library ABI doesn't
depend on the -std option.



More information about the Libstdc++ mailing list