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

[Didier Roche]

Le 13/06/2012 06:36, Tim Penhey a écrit :
> 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.
>
I think Tim is right, and even if we commit to do that, I guess we will 
have other developers using the c++11 standards that are not shipped 
into the distribution. Ignoring them is not something we should do IMHO. 
So "fixing/rollbacking" just Unity doesn't solve the whole problem.

Didier
> Tim
>