This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
GCC compatibility of shared libraries with STL objects in their interface
- From: Robert Fanner <robert dot fanner at gmail dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Sun, 29 Nov 2015 23:19:20 +0200
- Subject: GCC compatibility of shared libraries with STL objects in their interface
- Authentication-results: sourceware.org; auth=none
Hi,
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.
(If anyone is a StackOverflow user, I've posted the same question
there: http://stackoverflow.com/q/33958773/601626).
Any help or advice would be greatly appreciated.
Kind Regards,
Rob