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