From: Sven M. H. <pe...@gm...> - 2001-05-19 17:07:44
|
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. Regards, Sven -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |