Re: Mixing libstdc++.so.3/5

[Benjamin Kosnik <bkoz at redhat dot com>]

>The scenario (the OpenOffice.org suite) is as follows:  There is a 
>process composed of C++ shared objects built with GCC 3.2.2 (depending 
>on libstdc++.so.5.0.2).  This process can dynamically load in additional 
>components.  Some of the components would be built with GCC 3.0.1, so 
>they would also bring libstdc++.so.3.0.1 into the process.  Those 
>components are loaded RTLD_GLOBAL, so any symbols needed by those 
>components that are available in both versions of libstdc++ would be 
>taken from libstdc++.so.5.0.2 (which comes earlier in the search tree). 
>  I noticed that none of the symbols exported by either version of 
>libstdc++ are versioned.  The functionality the process and the 
>additional components actually use from libstdc++ is mostly the __cxa 
>and namespace __cxxabiv1 symbols; the namespace std stuff should be 
>mostly ignored, as all C++ code is built against the STLport (using 
>libstlport_gcc.so).

You are correct that libstdc++.so.3.x is unversioned, but
libstdc++.so.5.x and above should all have versioned symbols (in
GLIBCPP) on the platform you are referencing (ia32 linux). You can
double check this by 

%objdump --dynamic-syms libstdc++.so.5.0.x

and looking at the output. If you don't see versioning, you're doing
something wrong, or have explicitly turned it off.

Furthermore, it looks like all you are using is libsupc++, which also
should also be similarly versioned (in CXXABI). 

>A small test suggests that mixing libstdc++.so.3.0.1 and 
>libstdc++.so.5.0.2 in one process works (even passing exceptions), but I 
>don't feel too well with such experimentation only.
>
>Can anybody tell me whether my test working properly is either by sheer 
>luck or by design?

I suspect it is by luck, but I don't really know. There is no ABI
compatibility between 3.0.x and 3.2.x, as stated in both the gcc and
libstdc++ ABI docs. You might want to read them.

http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt
http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html#Compatibility

If you set LD_DEBUG=bindings in your environment, and then run your
dynamically linked process, you can see where the dynamic linker is
finding symbols to load. That should probably tell you what you want to
know.

best,
benjamin