[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help neede with automake and Mesa 4.x

From: Tom Williams
Subject: Re: Help neede with automake and Mesa 4.x
Date: Sun, 14 Jul 2002 23:01:12 -0700

Tom Tromey wrote:

> >>>>> "Tom" == Tom Williams <address@hidden> writes:
> Tom> Thanks for the info.  I'm using automake version 1.6.2 and
> Tom> libtool version 1.4.
> According to your, you're using automake 1.4-p5:

Well, *I* have automake 1.6.2 installed but I guess the Mesa developers use
automake 1.4-p5.  :)

> Tom> # generated automatically by automake 1.4-p5 from
> Anyway, digging through the and Makefile, it looks like we
> try to tell libtool to use g++ to link the library.  Is this what you
> see at `make' time?  (Something like "libtool --mode=link g++ ...")

Yup... I DO see those libtool lines during the compile, but I see "gcc -shared
{blah} -o {blah}" when the library is built.  As a test, I did this:

$ ln -s /usr/bin/g++ gcc
$ export PATH=.:$PATH

This caused libGLU to be created with g++ and my libGLU is now GOOD!  :)

> If so, then you've probably hit a libtool problem.

I guess so....  I'll attach the link output of the libGLU link which better
illustrates what I'm seeing.

> Tom> this results in a "__gxx_personality_v0" undefined symbol error
> Tom> when any app that links to libGLU runs.  This undefined symbol is
> Tom> due to C++ exception processing that I think is erroneous being
> Tom> linked in since that symbol is used for Java exceptions.
> __gxx_personality_v0 is definitely not used for Java exceptions.  It
> is the personality function for non-sjlj C++ exceptions.  Java
> exceptions use __gcj_personality_*; see gcc/libjava/
> Also note there is some text in the gcc manual describing what you
> must do in this area.  Search for -shared-libgcc.

Attached is the info I found in the gcc texinfo doc that discusses this issue

> However, it seems to me that (1) libtool probably should handle this
> automatically, and (2) libtool should be using g++ to link for you
> anyway, in which case g++ itself handles this problem.
> Tom

So, this is a libtool problem and NOT a automake problem?   It looks like some 
the OTHER libs in the libGLU shared library are compiled by gcc while some are
compiled with g++.  When I link libGLU with g++, all is well.  When I link the
gcc, things are broken.   So, maybe libtool is getting confused by the mixture 
C and C++ code in the library?


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 
       void foo() 
         S s; 

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. 
make[1]: Entering directory `/home/tom/Mesa-4.0.3/si-glu'
/bin/ksh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 
g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wp,-MD,.deps/dummy.pp -c  
-fPIC -DPIC -o dummy.o
mv -f dummy.o dummy.lo
/bin/ksh ../libtool --mode=link g++  -g -O2  -o -rpath /usr/X11R6/lib 
-version-info 4:403:3 -L../src dummy.lo -lGL libnurbs/interface/ 
libnurbs/internals/ libnurbs/nurbtess/ libtess/ 
mkdir .libs
rm -fr .libs/ .libs/libGLU.* .libs/libGLU.*
(cd . && ln -s dummy.lo dummy.o)
gcc -shared  dummy.lo -Wl,--whole-archive libnurbs/interface/.libs/ 
libnurbs/internals/.libs/ libnurbs/nurbtess/.libs/ 
libtess/.libs/ libutil/.libs/ -Wl,--no-whole-archive  
-L/home/tom/Mesa-4.0.3/src -lGL libnurbs/interface/.libs/ 
libnurbs/internals/.libs/ libnurbs/nurbtess/.libs/ 
libtess/.libs/ libutil/.libs/       -Wl,-soname 
-Wl, -o .libs/
(cd .libs && rm -f && ln -s
(cd .libs && rm -f && ln -s
(cd .libs && rm -f && ln -s ../
make[1]: Leaving directory `/home/tom/Mesa-4.0.3/si-glu'

reply via email to

[Prev in Thread] Current Thread [Next in Thread]