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

[Chase Douglas]

On 06/12/2012 10:30 AM, Matthias Klose wrote:
> 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."""

If I understand the comment correctly, this can be distilled to:

App calls func(), which is defined by both lib1 and lib2. lib1 and lib2
have different ABIs. App crashes when linked in the wrong order because
the called func() may have a different ABI than the app expects.

If I'm right, there's nothing here that is new due to the use of
different C++ standards. It's a simple ABI mismatch. Am I missing something?

-- Chase