shared library + symbol export + STL = inherently fragile...?

[tetsujin]

Hi, I have come across this problem in the past and I was wondering if there's any kind of sensible way around it...

Basically, I have a piece of functionality I want to implement in C++, as a shared library. The interface to the library is C but internally things are implemented with C++. Further, I want to use the standard library.

This would be all fine and good except for three things:
1: the particulars of the implementation of the STL can change from revision to revision
2: some of the STL is implemented in headers (templated and probably inlined) and some in a shared library
3: (this is the big one!) executables can be linked such that their symbols are exported to any loaded shared objects

What this means is that, if the C++ standard library version used by the shared object doesn't match that of the executable that's loading it, bad things happen. A piece of inlined code may "construct" an object, while a piece of standard library shared code may set fields in an assignment, or handle container insertion, things like that. I suppose this would occur in any case of library version mismatch, but C++ seems to make the setup for this kind of fall much more convenient.

As a result, I'm somewhat scared to use the STL in any shared objects I write - despite the fact that I find the library very useful... I'm just not sure the risk of runtime breakage is worth it. And I don't know if the issue can be resolved by distribution package dependencies and so on...

Is it just me or does this symbol-export thing not make a lot of sense? I guess I can see where it would be useful for implementing things like "errno" but isn't it pretty much screwed-up and dangerous the rest of the time?

And is there a good way to deal with this with libraries written in C++, or does one need to reimplement or avoid the STL to avoid the problem?

Thanks...

[JohnGraham]

It might not be as big a problem as you think - don't forget, shared libraries export the names (including versions) of the libraries they depend upon. So if you link against libstdc++.so.6.0.13, people will only be able to use your library against a compatible version - otherwise, they'll have to recompile (if you distribute source code).

Or you can just make sure you statically link with libstdc++.a - your library will be bigger, though.

[Rubberman]

Accessing C++ functionality (including STL classes and functions) from a C application can be problematic. Usually it entails creating some C-binding (extern "C") wrapper functions that are implemented with C++, but declared extern "C" to give them C-accessible bindings. Inside those functions you can do your C++ stuff. I've had to do this in the past for some major C++ applications that still needed to be accessed by old-style C programs. In any case, it is a royal PITA to deal with, and is a maintenance nightmare, IMHO.

[tetsujin]

It might not be as big a problem as you think - don't forget, shared libraries export the names (including versions) of the libraries they depend upon. So if you link against libstdc++.so.6.0.13, people will only be able to use your library against a compatible version - otherwise, they'll have to recompile (if you distribute source code).

This still doesn't protect people who load the library dynamically though (via dlopen(), etc.), right?

Or you can just make sure you statically link with libstdc++.a - your library will be bigger, though.

Unless I'm mistaken, I think even that won't do the trick. Symbol export can override any symbols built into the library, unless you load the library with the feature disabled...

I don't know, maybe in practice, for people with a fuller understanding of the relevant linker options, it's not a big deal. But it's something I've dealt with, an actual bug in production code, as a result of mismatched C++ libs in modules built at different sites... That's part of why I'm trying to learn more about my options for solving this.