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

[Matthias Klose]

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.

> 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.

> In addition to welcoming other people's opinions, I also want to make
> sure that other people are careful here don't fall in to the same trap :)

and we will have to scan the build logs for the use of the -std={c,gnu}++{0x,11}
flags to find problematic packages. will be fun for all the quiet cmake builds.

  Matthias

Further information:
  http://gcc.gnu.org/ml/gcc/2012-05/msg00409.html
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646