[Mesa3d-dev] libtool (was CVS and SSE)

[Brian P. <br...@va...>]

"Sven M. Hallberg" wrote:
> 
> On Fri, May 18, 2001 at 04:19:59PM -0600, Brian Paul wrote:
> > Dieter Nützel wrote:
> > >
> > > Am Freitag, 18. Mai 2001 23:22 schrieb Sven M. Hallberg:
> > > > On Fri, May 18, 2001 at 10:14:29PM +0200, Dieter Nützel wrote:
> > > > > gcc -O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
> > > > > -fschedule-insns2 -fexpensive-optimizations -Wall -fomit-frame-pointer
> > > > > -ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2
> > > > > -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -o
> > > > > .libs/aaindex aaindex.o ../src-glut/.libs/libglut.so -L/usr/X11R6/lib
> > > > > -lSM -lICE -lXmu -lXext -lXi -lX11 ../si-glu/.libs/libGLU.so
> > > > > ../src/.libs/libGL.so -lglide3 -lSM -lICE -lXmu -lXext -lXi -lX11
> > > > > -lpthread -lm -Wl,--rpath -Wl,/opt/Mesa/lib ../src/.libs/libGL.so:
> > > > > undefined reference to `grBufferSwap'
> > > >
> > > > grBufferSwap must be a function from glide.h, I think. Can you check that?
> > > > You're using Glide 3, right?
> > >
> > > It was autodetected. But I only use the DRI (CVS) with the included Mesa
> > > (3.4.2, now). I try Mesa CVS (3.5) regularly for the Mesa-3.5 DRI branch.
> > >
> > > > We've had some problems in the past with Glide
> > > > 3 headers or libraries getting mixed up with Glide 2 headers or libraries;
> > >
> > > I have only the Glide3 headers installed.
> > >
> > > > you might want to check on that, too. Try to find out where grBufferSwap is
> > > > supposed to come from (David, maybe you know?). Please let me know about
> > > > anything you find out. Thanks.
> > >
> > > You are right. It's in glide.h
> > >
> > > FX_ENTRY void FX_CALL
> > > grBufferSwap( FxU32 swap_interval );
> 
> Well now that is strange. Maybe use a debugger or such to check if
> grBufferSwap is _really_ defined inside libglide3 (if you care, see below).
> 
> > I think I'd like to see a configure option to explicitly disable the
> > 3dfx (FX) driver.  When building Mesa 3.5 for DRI you don't really
> > want to use any of the FX driver code.
> 
> --without-glide. :)
> 
> > Right.  It should be libGL.so.1.2.030500
> >
> > -Brian
> 
> Oh! I've _completely_ overlooked that nuance *laugh*. The cause for the above
> is my use of the -release libtool switch to specify the version number.
> Now I also understand what someone mentioned before about libtool complaining
> about incorrect version number format! If you use -version-info 1.2.030500
> libtool (absolutely correctly!) complains that 1.2.030500:0:0 is not a valid
> version information.
> 
> I've reread the libtool docs (info libtool) as well as the Linux OpenGL ABI
> (http://oss.sgi.com/projects/ogl-sample/ABI/). I encourage everyone in the
> discussion to check the libtool docs, too! The relevant sections are "Libtool
> paradigm" and "Versioning".
> 
> After some thought I have come to the conclusion that the library file naming
> scheme should be redesigned because, basically, I believe libtool's argument
> about library versioning is correct and should be followed.
> 
> It was suggested before to "fix libtool's idea of a version number". As I see
> it, that statement as invalid. Libtool doesn't have any idea of a "version
> number" in this case. Libtool considers "interfaces" because the interface(s)
> a library exports are what is really important about it. Not the version
> number of the package it came from. There are better ways of keeping track of
> the latter.
> 
> I'm not going to recite libtool's reasoning now, please read those docs.
> I'm assuming understanding of the libtool version info scheme below.
> 
> Satisfying both libtool and the Linux ABI, I suggest this:
> 
> - Set a libtool -version-info of 0:MESA_VERSION:0 where MESA_VERSION would be
>   30500 for Mesa 3.5.0.
> - Follow the rules for libtool version info in updating the CURRENT and AGE
>   fields.
> - On Linux (for ABI-conformance), use an install-hook to create two symbolic
>   links: libGL.so.1 to libGL.so.0.MESA_VERSION.0 and libGL.so to libGL.so.1.
> - Follow the same rules for GLU and GLUT.


I've been using the libGL.so.1.2.0x0y0z convention for a while now and
people seem to like it.  I really don't want to change the convention
yet again.

I realize that libtool tries to formalize the version numbers assigned to
a library and that's fine.  But sometimes a library has to be numbered
according to long-established conventions that don't match libtool's
method.

IMHO, libtool should have an option to support arbitrary version numbers.

Anyway, we seemed to have made libtools accept the 1.2.0x0y0z convention
in recent versions.  Why can't we continue with that?

-Brian