Mike Hearn <[EMAIL PROTECTED]> 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
