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

[Tim Penhey]

On 13/06/12 04:47, Didier Roche wrote:
> Le 12/06/2012 18:22, Matthias Klose a écrit :
>> On 08.06.2012 17:10, Chris Coulson wrote:
>>> I've just finished debugging a Unity crash which occurs when we try a
>>> test rebuild of Unity and Nux with GCC4.7 in quantal. Although the
>>> original issue was caused by mixing 2 C++ ABI's (because libsigc hasn't
>>> been rebuilt yet in quantal), it was no better even after rebuilding
>>> libsigc with the quantal toolchain.
>> correct, afaics there is no ABI incompatibility between 4.6 and 4.7,
>> but between
>> c++98 and c++0x/c++11.
>>
>> c++98 and c++0x/c++11 code should not be mixed in one binary, and best
>> avoided in a distribution.

This here is the kicker.

>>> What is happening is, in GCC4.7, std::_List_base::_List_impl has a data
>>> member which only exists for compilation units that are built with
>>> -std=c++0x (_M_size). This means that the STL ABI is dependent on the
>>> language standard. This obviously causes issues when a process loads
>>> libraries that are built with different language standards and which
>>> pass std::list's across public API's
>> indeed, this is the one issue, which is new in 4.7, so you didn't see
>> it in
>> precise with 4.6.
>>
>>> In the Unity case, both Unity and Nux are built with -std=c++0x, but
>>> they use libsigc which is not built with it and which exposes STL
>>> objects in its public API. Rebuilding libsigc locally with -std=c++0x is
>>> sufficient to make Unity work properly. However, uploading this will
>>> probably break anything else in the archive using libsigc which isn't
>>> built with -std=c++0x, so I'm not sure of the best way to proceed.
>> both -std=c++0x and -std=c++11 are still marked as experimental. So
>> don't use
>> them :-/ I don't think that building c++ libraries for both modes is
>> the right
>> approach, so let's avoid that for now, until the c++11 support in 4.7
>> is more
>> complete, and maybe not experimental.

Hmm... not entirely sure about this.  I'm hoping we can find a different 
solution.

> Yes, indeed, the situation is suboptimal. as this feature is marked as
> experimental. However, I'm afraid that we have an issue about this.
> Indeed, Unity is written using a lot of c++11 facilities, and taking it
> out won't be trivial now AFAIK. I'm CCing Tim who can give more
> information about it.

We started using the --std=c++0x flag about 10 months ago.  A large 
amount of the code that has been added over that time is using the more 
stable parts of the C++11 standard:
  * auto variable type
  * range based for loops
  * strong enums
  * lambda functions

Taking those out would be a massive task.

Tim