This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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]

GCC compatibility of shared libraries with STL objects in their interface


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


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