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

This change was reverted on Jun 23 in gcc-4.7 4.7.1-2ubuntu1.

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

The complete reversal of the offending patch (with the same effect) is on the
gcc-4.7 branch and will get into quantal with the next merge.

Please note that just using gcc-4.6 will help for this particular issue, but
it's not about a 4.6/4.7 issue, but about mixing c++98 and c++11 code.  The
c++03/c++11 support in GCC has always been marked as experimental, and still
is, so you may run into another incompatibility.

There is a discussion going on what can be done about the compatibility, see
http://gcc.gnu.org/ml/gcc/2012-07/msg00031.html, but for now just be aware
that this compatibility is not granted.

If your mixed mode code is known to work with gcc-4.6, then use gcc-4.6 to build
your c++03/c++11 code, however it's no guarantee that you will not run into
other (yet unknown) or documented ([1]) incompatibilities.

I'll go over the build logs to see which packages were built using g++-4.7 in
c++11 mode and rebuild these.  However this won't catch all these packages with
nice, short and maybe colored build logs, so if you maintain such a package,
better make the build log verbose ...

  Matthias

[1] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility