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

[Chase Douglas]

On 06/08/2012 08:10 AM, Chris Coulson wrote:
> Hi,
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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 :)

I would have assumed that language standard choices should be
intermixable across libraries. Is it possible this is merely a bug in GCC?

-- Chase