GCC 4.7, STL and binary compatibility of objects built with different language standards

[Matthias Klose]

On 12.06.2012 19:18, Matthias Klose wrote:
> On 12.06.2012 18:50, Chase Douglas wrote:
>> My understanding is that this is only a problem if one library compiled
>> with one standard passes objects to another library compiled with
>> another standard. The following examples illustrate the difference:
>>
>> * Nux (c++11) and libsigc++ (c++98) are compiled with different
>> standards. They pass std::lists between them. This is a problem.
>>
>> * utouch-grail (c++11) and utouch-qml (c++98) are compiled with
>> different standards. However, the API between the two is pure C. This is
>> not a problem.
>>
>> Please correct me if I am wrong.
> 
> please read the referenced GCC report.

from http://gcc.gnu.org/PR53646 (but see the issue itself for the complete
description):

"""The testcase consists of two libraries (lib1 lib2), compiled with cxx11
and cxx98 respectively.  Both libs don't depend or interact with each other.
The app stands for a random application making use of random libraries,
calling simple functions in them, which themself don't exhibit any ABI
problem.  I.e. the testcase tries to show a typical situation for
application developers using several different 3rd party libraries not under
control of that developer.

The problem happens because both libs contains a (weak) definition of
the equal_range function.  As the libs don't control their exports this
symbol also is exported.  Hence the calls will be resolved to whatever
version comes first in dynamic linker search order (that's the reason
for the two apps built, once with "-l1 -l2", once with "-l2 -l1").

So, whichever library is first in search order, the other library will
resolve its own equal_range call (stemming from the inlined erase) to that
first library, and thereby crash because that version was compiled with
different c++ ABI."""