GCC compatibility of shared libraries with STL obj

问题:

I have an application with STL objects used as part of the C++ interface for plug-in writers.

I know the best option for compatibility would have been to use a C interface instead, but that's not currently feasible.

I know that everything from GCC 3.4 to 4.8 in libstdc++ has been highly compatible in terms of ABI.

So for example, if I compile with GCC 4.1, and a plug-in vendor writes code compiled with GCC 4.7, then barring corner cases all will be well on a platform with a libstdc++ version corresponding to GCC 4.7 or later, provided STL useage is internal to the .so only, and that the external .so interface is using pure C, which sadly is not the case for me.

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?

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.

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.

回答1:

I already answered this on the mailing list but as Marc said, it will just work.

It doesn't make any difference whether you use the library internally to your DSO or in the interface, the library doesn't care and is backwards compatible back to GCC 3.4 either way.