This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/8847: dynamic_cast segfaults with shared lib
- From: bangerth at dealii dot org
- To: gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, hans dot utz at informatik dot uni-ulm dot de, nobody at gcc dot gnu dot org
- Date: 6 Dec 2002 17:12:59 -0000
- Subject: Re: c++/8847: dynamic_cast segfaults with shared lib
- Reply-to: bangerth at dealii dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, hans dot utz at informatik dot uni-ulm dot de, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: dynamic_cast segfaults with shared lib
State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Fri Dec 6 09:12:57 2002
State-Changed-Why:
I can confirm the problem with a slightly smaller program:
------------------------------
struct Foo {
virtual ~Foo(){};
};
struct myBar : public Foo {
virtual ~myBar(){};
};
int main(int, char **)
{
dynamic_cast<myBar *>((Foo*)new myBar());
return 0;
}
----------------------------------
Linking with libGLU alone suffices to crash the program.
However: on my system, which is very much like yours,
libGLU and libGL are located in /usr/lib, i.e. are
system libraries and are thus probably compiled with
gcc 2.95. In contrast to libGL, libGLU has C++ symbols
in it, so I am pretty sure that the problem stems from
the ABI incompatibilities between the 2.95 C++ compiler
and the 3.2 C++ compiler. This has to be expected. Linking
C++ libraries together that have not been created with the
same compiler asks for trouble (or at least did, prior to
the standard gcc is trying to follow since 3.2). Can you
report what happens if you try to use a libGLU that is
compiled with the same compiler as the one you use
for the rest of the project, i.e. 3.2.1?
Thanks
Wolfgang
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8847