Re: Help neede with automake and Mesa 4.x

[Tom Williams]

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 Makefile.in, 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> # Makefile.in generated automatically by automake 1.4-p5 from Makefile.am
>
> Anyway, digging through the Makefile.in 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 libGLU.so {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/except.cc.
>
> 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
exactly...

>
> 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 
of
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 
of
C and C++ code in the libGLU.so library?

Peace....

Tom

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.

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