GCC 4.7, STL and binary compatibility of objects built with different language standards
tim.penhey at canonical.com
Wed Jun 13 04:36:34 UTC 2012
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
> 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.
More information about the ubuntu-devel