loading multiple C++ runtimes but not mixing ABIs?

[Ken Raeburn <raeburn@xxxxxxxxxxx>]

Is it possible, or safe, generally, to get two C++ runtimes loaded  
into one address space via different shared libraries, as long as you  
don't pass C++ objects or exceptions around between them?

I'm evaluating using C++ internally for a library, to get limited use  
of a few features like exception handling and templates, maybe an STL  
container template or two.  The API for the library in question is  
purely a C API, and would stay that way.  So aside from this shared  
library dragging in the C++ runtime code, it should theoretically be  
transparent to the application that C++ is being used.  All API  
functions would trap exceptions and turn them into error codes, all  
storage allocations have deallocation functions provided too so new/ 
malloc should be an internal distinction only, etc.

My concern is about applications using this library in cases where  
the application or another library uses C++, and isn't built with the  
same compiler, library version, etc.  They could use different  
versions of gcc, or one might use the vendor's tools.  That might  
also imply that symbol versioning isn't necessarily in use, though  
I'd hope the vendor does a smart job of updating library major  
version numbers as needed, and supports dependencies in shared  
libraries.

http://gcc.gnu.org/onlinedocs/libstdc++/abi.html suggests at the end  
that "mixing C++ ABI's is not recommended at this time", though I  
don't see a last-update time on it, and the two bug reports it refers  
to are marked "resolved".  Is what I'm considering still considered a  
bad idea?

My guess is that in at least some cases of older systems we might  
lose.  But how much trouble would we be in?  If it comes down to  
something like "you'd have to use modern GNU tools on system X", that  
might be okay, if X isn't terribly popular...

Ken