C++ ABI mismatch crashes

[Dan Kegel]

Mike Hearn <mike@navi.cx> wrote:
> I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4
> based system. All of the C++ libraries it links directly against, like
> GTKmm, are statically linked. In other words, it dynamically links
> against no C++ libraries.
> 
> Inkscape dlopens libgtkspell, which in turn dlopens libaspell (to add
> a spelling checker). libgtkspell is written in C, but libaspell is written
> in C++ and exposes a C interface.
> 
> This causes a crash ...
> 
> Note that on the first line libaspell is being bound to libstdc++.so.6,
> which is what I'd expect as libaspell is compiled using gcc 3.4 - and
> indeed up until this point it's been linked only against libstdc++.so.6.
> Then for some reason it's linked against libstdc++.so.5, for the following
> symbol:
> 
> _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_S8_

[I'm going to regret posting in a hurry, but here goes:]

Hmm!  Quick question: if you rebuild libaspell (with the same
version of g++ as it was built before) to link in the C++ library statically,
does that fix the crash?

One possible conclusion we could draw might be
"Libraries that export only C APIs but
are written in C++ should be statically linked against
the C++ standard library.
Once the gcc C++ ABI stabilizes,
i.e. once all the remaining C++ ABI compliance bugs have
been flushed out of gcc, this requirement can be relaxed."

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

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html