Question about __gxx_personality_v0 undefined symbol

Tom Williams tomdkat@attbi.com
Thu Jul 4 16:28:00 GMT 2002


Hi!  Ok, I'm trying to build Mesa-4.0.3 using the gcc 3.1.1-20020701
snapshot (as well as the production gcc-3.1 compiler) and Mesa compiles
just fine, but the libGLU.so library refers to a missing
"__gxx_personality_v0" symbol.

Now I've been searching long and hard for info on this error and all
I've been able to find are occasional messages about OTHERS encountering
this SAME error.  FINALLY I ran across this in the gcc documentation:

Java Exceptions
===============

   The Java language uses a slightly different exception handling model
from C++.  Normally, GNU C++ will automatically detect when you are
writing C++ code that uses Java exceptions, and handle them
appropriately.  However, if C++ code only needs to execute destructors
when Java exceptions are thrown through it, GCC will guess incorrectly.
Sample problematic code is:

       struct S { ~S(); };
       extern void bar();    // is written in Java, and may throw
exceptions
       void foo()
       {
         S s;
         bar();
       }

The usual effect of an incorrect guess is a link failure, complaining of

a missing routine called `__gxx_personality_v0'.

   You can inform the compiler that Java exceptions are to be used in a
translation unit, irrespective of what it might think, by writing
`#pragma GCC java_exceptions' at the head of the file.  This `#pragma'
must appear before any functions that throw or catch exceptions, or run
destructors when exceptions are thrown through them.

   You cannot mix Java and C++ exceptions in the same translation unit.
It is believed to be safe to throw a C++ exception from one file
through another file compiled for the Java exception model, or vice
versa, but there may be bugs in this area.

Now, the libGLU library DOES get compiled with g++ since it's
inplemented in C++, but I don't understand WHY the Java exceptions are
being involved at all.

When I built gcc-3.1.1-20020701, I specified these arguments:

$ ../configure --prefix=/usr --enable-languages=c,c++ --enable-shared
--with-threads=posix

When the configure script first ran, it mentioned my configuration would
NOT work in the Java, Fortran, and Objective-C directories, which is
usual.

Is this a bug in the C++ front-end or is the Mesa C++ code poorly
written?

Thanks in advance for your time!

Peace....

Tom



More information about the Gcc-help mailing list