This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ ABI mismatch crashes
- From: Mike Hearn <mike at navi dot cx>
- To: Dan Kegel <dank at kegel dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 18 Apr 2005 15:22:21 +0100
- Subject: Re: C++ ABI mismatch crashes
- References: <426319DA.6030809@kegel.com>
On Sun, 2005-04-17 at 19:22 -0700, Dan Kegel wrote:
> But I can't shake the feeling that it's crazy that libaspell
> got linked against two different C++ libraries. Can you
> try creating a minimal test case demonstrating this
> without involving inkscape? If so, maybe it's a glibc
> shared library loader bug?
This thread got moved to the libstdc++ list. I have created a minimal
test case which also shows a misbind of the std::string + op overload:
http://gcc.gnu.org/ml/libstdc++/2005-04/msg00177.html
I'm afraid any solution that involves statically linking (or changing)
libraries like aspell won't work for me. I need to find a fix that can
be deployed in the field.
I am currently trying to bring myself up to speed on how all this works,
but the C++ ABI is pretty complicated. I'm still trying to figure out
exactly what COMDAT sections are, and how template instantiation works
at the ELF level. Joe suggested that it seems to be related to this.
I thought (but I must be wrong) that COMDAT sections and weak symbols
were only put into .o files: once the .o files are combined into the
final binary or shared library, the compile time link editor merges the
definitions into a local symbol. I also still don't understand why the +
op overload is showing up in the symbol table at all. I thought methods
defined in headers would just be fancily copy/pasted into wherever they
were used.
thanks -mike