13

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.

Rob
  • 1,350
  • 12
  • 21
  • 1
    Unless people are going out of their way to make it fail, it should work just fine. – Marc Glisse Nov 28 '15 at 20:44
  • @marc Thanks for the feedback. Any chance you can provide a reference or a link that goes into this in a bit more detail (or perhaps projects that rely on this)? – Rob Nov 28 '15 at 21:49
  • 1
    It will not necessarily work, though, for gcc >= 5.0, since they [changed their ABI](https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html) – Walter Dec 06 '15 at 00:22
  • Thanks @Walter - Jonathan pointed out the same thing on the mailing list, so I'm aware of the library binary interface changing for 5.0 for things like std::string. – Rob Dec 08 '15 at 20:28

1 Answers1

7

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.

Rob
  • 1,350
  • 12
  • 21
Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • Many thanks for the answer! I'll accept it, because you're an authority on libstdc++. As mention on the mailing list, if there is any documentation you can point me towards about how you went about achieving the consistently high degree of ABI compatibility (e.g. making sure memory layout remains consistent, inlining remains consistent, etc.), then I'd appreciate it. – Rob Nov 30 '15 at 07:32
  • @Jonathan Wakely What if you get a scenario where new/malloc is done inside the lib, the pointer somehow propagates to the user's application and delete/free is done there? I have seen scenarios where there are more than one libc version and more than one memory allocator in the same application, and the above scenario could then cause the application to crash. – Erik Alapää Dec 04 '15 at 15:26
  • @ErikAlapää, having more than one libc is your problem, not libstdc++'s problem. The standard says the allocation functions are global, if you violate the One Definition Rule by having multiple incompatible allocation functions then you need to deal with it yourself. – Jonathan Wakely Dec 04 '15 at 16:40
  • @JonathanWakely I wanted to point out the problem nonetheless - it has bitten many a programmer. – Erik Alapää Dec 05 '15 at 08:27