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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux