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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
