From: Jean-Francois Panisset (panisset++at++discreet.com)
Date: 06/21/2001 13:09:29
<200106210900.CAA21533++at++holodeck.engr.sgi.com>info-performer Mailing List write
>
> From: Markus von der Heyde <MvdH++at++Kyb.Tuebingen.MPG.de>
> Date: Wed, 20 Jun 2001 12:09:35 +0200
> Subject: using dynamic_cast with Performer lib
> Reply-To: Markus.von.der.Heyde++at++Tuebingen.MPG.de
>
>Hi,
>
>as soon as I integrate a dynamic_cast into a program with is linked
>with the Performer lib (-lpf) I get a segmentation fault.
>
>(gdb) bt
>#0 0x0 in ?? ()
>#1 0x40712568 in __user_type_info::dyncast (this=3D0x8049b38, boff=3D0=
>,=20
> target=3D++at++0x8049b38, objptr=3D0x8055078, subtype=3D++at++0x8049b44, subp=
>tr=3D0x8055078)
> from /usr/lib/libstdc++-libc6.2-2.so.3
I've run into these kinds of problems myself, and they were caused
by having two separate versions of the C++ runtime loaded at the
same time. Try:
ldd my_app_name
If you have two separate versions of libstdc++ dynamically linked
against your app, that's the kind of problems you will run into.
This typically happens when you are using gcc 2.96 (which will
link against /usr/lib/libstdc++-3-...), but are also linking
against DSOs compiled with an older version of the compiler,
themselves referencing /usr/lib/libstdc++-2-....
If this is the case, run ldd on each of the DSOs you are linking against
to find the culprit. Once you have found it, if you have source for
that DSO, recompile it with gcc 2.96. Otherwise, you might be able
to fool the runtime loader by playing games with symlinks in /usr/lib
to make sure that everyone gets /usr/lib/libstdc++-3..., although
that's a bit tricky (and everytime you reinstall stuff on your
machine, the symlinks may get overwritten back to what they were
before).
Isn't the lack of a standard C++ ABI a great thing? And it will
only get worse with gcc 3.0, which breaks that completely once again...
JF
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 13:07:32 PDT