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

[Steve Langasek]

Hi Bjoern,

On Mon, Jul 02, 2012 at 06:11:40PM +0200, Bjoern Michaelsen wrote:
> 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

This bug report seems to only include backtraces for libreoffice when built
with C++0x.  Can you provide a backtrace for the most recent crash, when
libreoffice has been built with C++98?

Also, the upstream bug report includes what I assume is enough information
for someone already familiar with libreoffice to reproduce the problem, but
I'm not familiar with its build system and find the test case a little
opaque.  Can you provide reproducer instructions for this, preferably ones
that someone could follow to reproduce the problem *quickly* (i.e., without
having to do their own full local libreoffice build, which isn't exactly
quick)?

If that's not possible, can I suggest trying to capture the output of the
executable used for the test when run with LD_DEBUG=bindings, and post the
output of a grep for std::list symbols?  (May require running the output
through c++filt first for demangling.)  According to
<http://gcc.gnu.org/wiki/Cxx11AbiCompatibility>, should probably grep for
_List_impl and _List_base.

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

Unfortunately it's very hard to gather this information because there's no
mechanically-identifiable indication in the symbols of the resulting
libraries.  It *would* be mechanically detectable based on compiler
commandline options... except that there's an annoying trend lately for
build systems to hide these, so that we can't even analyze build logs to get
the answer.

So I think it would be better to approach this with runtime debugging
(LD_DEBUG), at least for narrowing the search.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120702/3643ac0b/attachment.pgp>