Binary compatibility between an old static libstdc++ and a new dynamic one

[Jonathan Wakely]

On 13 April 2017 at 14:26, Guilherme Quentel Melo wrote:
> Thanks for replying Jonathan
>
>
>> It's not supported to mix C++11 code compiled with 4.x and GCC 5+, in
>> any way, whether linking dynamically or statically.
>
> OK, but this is true even when the API is C? In this case no c++ structure
> is ever passed to mesa. If mesa was compiled with the new ABI, I should
> still be fine, right?

Right.

>> If you're only using C++98 (and of course only using the old COW
>> std::string in the code compiled with GCC 5+)
>
> Yeah, my gcc 5.x has _GLIBCXX_USE_CXX11_ABI=0 in the specs
>
>> This of course assumes both GCC versions are configured to be
>> compatible, i.e. you're not using --enable-fully-dynamic-string
>
> I'm not using many configure options, only
> --enable-version-specific-runtime-libs --disable-multilib
>
>
> So if this should work I will try to investigate it further, but I'm not sure
> what else I can do.
> gdb did not help much because if I recompile mesa without optimizations
> the crash does not happen.
>
> Actually disabling only inline optimization also makes the crash go away.
> Given that all invalid free stacks shown by valgrind contain inline functions
> from basic_string.h does that ring you any bells?
>
> Any other tips for debugging this?

I'm not sure what to check. If the symbols are equivalent then it
shouldn't matter whether a given symbol is inlined using the GCC 4.8.5
code or comes from the 5.4.0 shared library. But apparently it does,
so either the new library is not backwards compatible, or something
else is going on.