Re: Help needed with Mesa-4.0.3 build and libtool-1.4.2

[Tom Williams]

Thanks!  Is CVS the only way, at this point, to get access to the development
snapshots?  The link to libtool-1.4d.tar.gz on the libtool homepage does NOT
work and there is NO "libtool" directory on alpha.gnu.org, at least not from
anonymous FTP login.

Thanks!

Peace...

Tom

Bob Friesenhahn wrote:

> I believe that libtool 1.4e (CVS version) totally changes how C++
> libraries are linked.  The C++ compiler is used to link C++ libraries
> now so this problem should be gone now.
>
> Bob
>
> On Mon, 15 Jul 2002, Tom Williams wrote:
>
> > Hi!  I'm trying to get Mesa 4.0.3 properly built and I've learned
> > (through troubleshooting automake possible problems) that libtool is
> > using the WRONG compiler to build a shared libGLU.so library.
> >
> > libGLU.so contains code in C++ and some code in C.  When libGLU.so is
> > built, gcc is used to create the shared library when g++ needs to be
> > used instead.   As a result, the "__gxx_personality_v0 undefined symbol"
> > error is issued by ANY app that links to libGLU.so.
> >
> > Here is the output from the libGLU.so link part of the Mesa-4.0.3 build:
> >
> > make[1]: Leaving directory `/home/tom/Mesa-4.0.3/si-glu/libutil'
> > 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  -Wl,--rpath
> > -Wl,/home/tom/Mesa-4.0.3/src/.libs -Wl,--rpath -Wl,/usr/X11R6/lib
> > -L/usr/X11R6/lib -L/home/tom/Mesa-4.0.3/src
> > /home/tom/Mesa-4.0.3/src/.libs/libGL.so
> > 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'
> > address@hidden:~/Mesa-4.0.3/si-glu$
> >
> > Here, libtool is invoked with the "--mode=link g++" options but gcc is
> > used and NOT g++ to build libGLU.so:
> >
> > gcc -shared  dummy.lo -Wl,--whole-archive
> > libnurbs/interface/.libs/libNIFac.al
> > libnurbs/internals/.libs/libNInt.al  (etc)
> >
> > How can I find out WHY gcc is being used to link libGLU.so when g++ is
> > specified on the libtool command line?
> >
> > Should I try libtool 1.4d?
> >
> > I'm running this on Slackware Linux 8.0 w/ 2.4.18 kernel, gcc-3.1.1
> > (20020708 snapshot), glibc-2.2.5, automake 1.6.2, perl 5.8.0-rc1,
> > libtool 1.4.2, binutils-2.12.1.
> >
> > Thanks!
> >
> > Peace...
> >
> > Tom
> >
> >
> > _______________________________________________
> > Libtool mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/libtool
> >
>
> ======================================
> Bob Friesenhahn
> address@hidden
> http://www.simplesystems.org/users/bfriesen