GCC 4.7, STL and binary compatibility of objects built with different language standards
Bjoern Michaelsen
bjoern.michaelsen at canonical.com
Mon Jul 2 16:11:40 UTC 2012
Hi,
On Fri, Jun 08, 2012 at 04:10:38PM +0100, 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.
>
> 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 :)
So essentially this ABI breaker kills quantals for me for now. We have this
testcase heisenbug crasher:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1017125
which makes LibreOffice unstable on quantal, even though I am forcing a C++98
ABI build:
http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=patches/trying-to-force-CXX0X-off-for-ABI-incompatibility.diff;h=1fa52e078613a9125ba43823e0a68c2d6085aab5;hb=4d4f4d6035b67dc42d21bb705d3da6570f9f2c05
(I also tried a gcc 4.6 build -- it is unstable too). I dont know where I get
the trouble from, but in any of the IIRC >1000 source packages that LibreOffice
directly or indirectly depends upon there has to be the foul C++0x ABI. The fun
is to find out where. The same test is running with the same LibreOffice source
package on precise without any trouble or hickups in an overnight run with
more than 1200 iterations.
Do we have a list/wiki page/some other form of coordination showing the
packages that are:
- known to be clean C++98 ABI
- unknown
- known to be broken C++0x/gcc-4.7
If not, who will start one and where?
Best,
Bjoern
More information about the ubuntu-devel
mailing list