typeinfo problems due to different versions of gcc embeded into C API shared libraries

[Milan Cvetkovic]

Benjamin Kosnik wrote:
>>I have found that the problem is in A.so. It is internally using one of 
>>the previous releases of g++ (I believe g++-2.95.3), and it is exporting 
>>some C functions used by RTTI - I found one "__dynamic_cast".
>>
>>Obviusly, __dynamic_cast-2.95.3 cannot work with my_code-3.3.2, since 
>>the ABI changed. But the names of __dynamic_cast remained the same, even 
>>though the signature changed. So my code links with obsolete 
>>__dynamic_cast, and it core dumps when used :((
>>
>>Is there a way to overcome this problem?
> 
> 
> Not that I can see.

This is not good. and I still have troubles understanding why.

C++ABI is different between compilers, and between different versions of 
compiler.

If someone (library vendor):
- write a library that only exports "C" API, C structs, C datatypes
- internaly implement it using C++ using compiler "X"
- inside library, I use exceptions and dyncamic_casts and other
   things comming with rtti. I make sure that I catch all exceptions

And if the user of this library chooses to use C++, (s)he must use the 
compiler with the same ABI. Otherwise, on first usage of "dynamic_cast" 
inside the library, code will core dump.

To me, the ABI implementation inside the library should not interfere 
with the ABI implementation outside, if the API between them is "C" and 
there are no exceptions/type_info crossing the shared object boundary.

I can see that this is currently an issue with 2.95.3/3.x compilers. But 
it would be a good idea to think how to overcome this specific scenario 
in the future.

Milan.

> 
> 
>>Maybe in future releases of g++, the names of "C" functions related to 
>>ABI should "mangle" the ABI version, this would let others link with C 
>>libraries even though C++ ABI would have changed in the mean time.
> 
> 
> For gcc releases after gcc-3.2.x, symbol versioning is used on platforms
> that can support this feature. This can help with the versioning issue
> (provided both shared libraries have versioned symbols), but not with
> the incompatible ABI issue.
> 
> best,
> -benjamin