mesa3d-dev

RE: [Mesa3d-dev] CVS and SSE

[Dieter <Die...@ha...>]

> On Fri, Apr 27, 2001 at 09:59:03AM -0600, Brian Paul wrote:
> > One problem is still outstanding.  The src/X86/gen_matypes.c file must
> > be compiled and executed in order to generate src/X86/matypes.h before
> > the assembly code can be compiled.  You can do this manually:
> > 
> >       cd src/X86
> >       gcc gen_matypes.c -I.. -I../../include -o gen_matypes
> >       ./gen_matypes > matypes.h
> > 
> > I don't know how to make configure do this.  When I make the MesaLib-3.5
> > tarballs I'll include matypes.h so it won't be a problem for typical end
> > users.  We developers and CVS users just have to remember to regenerate
> > matypes.h whenever src/mtypes.h changes.
>
> Woohoo! This is done all nice and clean now! :) (Can you tell I'm proud?)
>
> src/X86/Makefile.am now includes a rule for building gen_matypes, one for
> generating matypes.h through it, as well as the dependency on matypes.h.
> Means: everything is done automagically once it is needed.
>
> Unfortunately the configure script depended on matypes.h in the checks for
> MMX etc. :o.
>
> I built small checks for all the assembler features in m4/assembler.m4 using
> just one instruction of the particular command set each. On my system this
> reports all command sets as available. However assembly is not my focus, so
> someone more comfortable with all that migh want to double-check the test
> cases.
>
> -Sven

Sorry Sven,

but I have still some problems...
Athlon with 3DNow!

SunWave1>./bootstrap
SunWave1>./configure --prefix=/opt/Mesa --without-svga --without-pic 
--enable-fast-install
SunWave1>time make check

[-]
mkdir .libs
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'
collect2: ld returned 1 exit status
make[2]: *** [aaindex] Error 1
make[2]: Leaving directory `/opt/Mesa/book'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/opt/Mesa/book'
make: *** [check-recursive] Error 1
351.110u 75.490s 14:46.01 48.1% 0+0k 0+0io 1820934pf+0w

And isn't the library name wrong?
SunWave1>l src/.libs/
insgesamt 2209
drwxr-xr-x    2 nuetzel  users         168 Mai 18 21:56 .
drwxr-xr-x   24 nuetzel  users        8256 Mai 18 21:56 ..
-rwxr-xr-x    1 nuetzel  users     2247751 Mai 18 21:56 libGL-1.2.030500.so
lrwxrwxrwx    1 nuetzel  users          11 Mai 18 21:56 libGL.la -> 
../libGL.la
-rw-r--r--    1 nuetzel  users         707 Mai 18 21:56 libGL.lai
lrwxrwxrwx    1 nuetzel  users          19 Mai 18 21:56 libGL.so -> 
libGL-1.2.030500.so

Shouldn't it be called something like this?

SunWave1>l /usr/X11/lib/libGL.so.1.2
-rwxr-xr-x    1 root     root       500591 Mai 18 05:34 
/usr/X11/lib/libGL.so.1.2
SunWave1>l /usr/X11/lib/libGLU.so.1.3.030500
-rwxr-xr-x    1 root     root       826425 Mai 18 00:37 
/usr/X11/lib/libGLU.so.1.3.030500

Thanks,
	Dieter

Re: [Mesa3d-dev] CVS and SSE

[Sven M. H. <pe...@gm...>]

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? We've had some problems in the past with Glide 3
headers or libraries getting mixed up with Glide 2 headers or libraries; 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.


> And isn't the library name wrong?
> SunWave1>l src/.libs/
> insgesamt 2209
> drwxr-xr-x    2 nuetzel  users         168 Mai 18 21:56 .
> drwxr-xr-x   24 nuetzel  users        8256 Mai 18 21:56 ..
> -rwxr-xr-x    1 nuetzel  users     2247751 Mai 18 21:56 libGL-1.2.030500.so
> lrwxrwxrwx    1 nuetzel  users          11 Mai 18 21:56 libGL.la -> 
> ../libGL.la
> -rw-r--r--    1 nuetzel  users         707 Mai 18 21:56 libGL.lai
> lrwxrwxrwx    1 nuetzel  users          19 Mai 18 21:56 libGL.so -> 
> libGL-1.2.030500.so
> 
> Shouldn't it be called something like this?
> 
> SunWave1>l /usr/X11/lib/libGL.so.1.2
> -rwxr-xr-x    1 root     root       500591 Mai 18 05:34 
> /usr/X11/lib/libGL.so.1.2
> SunWave1>l /usr/X11/lib/libGLU.so.1.3.030500
> -rwxr-xr-x    1 root     root       826425 Mai 18 00:37 
> /usr/X11/lib/libGLU.so.1.3.030500

Actually, I don't know. I don't think I touched the version number stuff...

Brian, please help!?


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 ]

Re: [Mesa3d-dev] CVS and SSE

[Dieter <Die...@ha...>]

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 );

>
> > And isn't the library name wrong?
> > SunWave1>l src/.libs/
> > insgesamt 2209
> > drwxr-xr-x    2 nuetzel  users         168 Mai 18 21:56 .
> > drwxr-xr-x   24 nuetzel  users        8256 Mai 18 21:56 ..
> > -rwxr-xr-x    1 nuetzel  users     2247751 Mai 18 21:56
> > libGL-1.2.030500.so lrwxrwxrwx    1 nuetzel  users          11 Mai 18
> > 21:56 libGL.la -> ../libGL.la
> > -rw-r--r--    1 nuetzel  users         707 Mai 18 21:56 libGL.lai
> > lrwxrwxrwx    1 nuetzel  users          19 Mai 18 21:56 libGL.so ->
> > libGL-1.2.030500.so
> >
> > Shouldn't it be called something like this?
> >
> > SunWave1>l /usr/X11/lib/libGL.so.1.2
> > -rwxr-xr-x    1 root     root       500591 Mai 18 05:34
> > /usr/X11/lib/libGL.so.1.2
> > SunWave1>l /usr/X11/lib/libGLU.so.1.3.030500
> > -rwxr-xr-x    1 root     root       826425 Mai 18 00:37
> > /usr/X11/lib/libGLU.so.1.3.030500
>
> Actually, I don't know. I don't think I touched the version number stuff...
>
> Brian, please help!?

I mean not the numbers but the "-" sign and the order of "so" and the numbers.

-Dieter

Re: [Mesa3d-dev] CVS and SSE

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

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 );


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.


> > > And isn't the library name wrong?
> > > SunWave1>l src/.libs/
> > > insgesamt 2209
> > > drwxr-xr-x    2 nuetzel  users         168 Mai 18 21:56 .
> > > drwxr-xr-x   24 nuetzel  users        8256 Mai 18 21:56 ..
> > > -rwxr-xr-x    1 nuetzel  users     2247751 Mai 18 21:56
> > > libGL-1.2.030500.so lrwxrwxrwx    1 nuetzel  users          11 Mai 18
> > > 21:56 libGL.la -> ../libGL.la
> > > -rw-r--r--    1 nuetzel  users         707 Mai 18 21:56 libGL.lai
> > > lrwxrwxrwx    1 nuetzel  users          19 Mai 18 21:56 libGL.so ->
> > > libGL-1.2.030500.so
> > >
> > > Shouldn't it be called something like this?
> > >
> > > SunWave1>l /usr/X11/lib/libGL.so.1.2
> > > -rwxr-xr-x    1 root     root       500591 Mai 18 05:34
> > > /usr/X11/lib/libGL.so.1.2
> > > SunWave1>l /usr/X11/lib/libGLU.so.1.3.030500
> > > -rwxr-xr-x    1 root     root       826425 Mai 18 00:37
> > > /usr/X11/lib/libGLU.so.1.3.030500
> >
> > Actually, I don't know. I don't think I touched the version number stuff...
> >
> > Brian, please help!?
> 
> I mean not the numbers but the "-" sign and the order of "so" and the numbers.

Right.  It should be libGL.so.1.2.030500

-Brian

Re: [Mesa3d-dev] CVS and SSE

[Sven M. H. <pe...@gm...>]

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 ]

[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

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

[Sven M. H. <pe...@gm...>]

On Mon, May 21, 2001 at 10:19:40AM -0600, Brian Paul wrote:
> > 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.

Those long-established conventions are reflected in the ABI. That's why I
suggested to create a symlink for the name libGL.so.1. However, that name (as
I overlooked) conflicts directly with the libtool scheme. See all the way
below for a solution.


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

No it shouldn't. See below.


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

The point is that what libtool places there where you want to put a version
number is not a version number at all. It's a certain code describing the
interfaces a library exports. That's also the reason why libtool performs that
check: Using traditional version numbers would result in interface information
that doesn't make sense. This could lead the dynamic linker to not linking a
program because the library it finds doesn't appear suitable, although it is.


I have just played around with libtool a bit because I was curious how it
would actually go about enforcing the run-time checking of the interfaces.
I found out that it actually uses (at least on Linux, that is) a _file_
_name_ scheme very (I'd like to say _exactly_) similar to the version
numbering scheme used by the OpenGL standard, which is (correct me if I'm
wrong) to reserve interface changes to major releases, keeping backwards
compatibility among all releases with the same major number.
 
Now what libtool does:
Out of the interface numbers CURRENT, REVISION and AGE (assuming you know
their meaning) it computes a version number of the form M.m.r
like this:
  M = CURRENT-AGE
  m = AGE
  r = REVISION
The name of the binary becomes:
  libX.so.M.m.r
Two symbolic links to it are created:
  libX.so
  libX.so.M
The resemblence to what we're used to is astonishing! However, the final part
is the one that is important, because it is the one that produces the run-time
interface checking semantics I was looking for:

Executables are linked using -soname=libX.so.M !

That naming convention, combined with the rules for the CURRENT, AGE, and
REVISION numbers from the libtool documentation have the effect that any
library which obsoletes some interface ("increment CURRENT, reset AGE") gets a
new major number while those that keep the old interfaces ("increment CURRENT
and AGE") retain the same M.

I don't know, maybe that discovery isn't new to you, but at least I couldn't
directly derive this from the libtool docs. :}


Anyways, knowing how libtool naming works and that OpenGL versioning is
compatible with it we can probably safely reverse the whole thing and
calculate libtool-style CURRENT and AGE from OpenGL M and m. :)

With M=1, m=2: CURRENT=3, AGE=2. Finally we can set REVISION to the Mesa
version number. Libtool doesn't allow leading zeroes, though; it wants nice
and plain integers. I say we just compute a nice and plain integer for it:

With Mesa major, minor and release numbers being MM, Mm, and Mr respectively:
  r = MM * 10^4 + Mm * 10^2 + Mr
I know this will effectively drop the leading zero, but I think we could
accept that compromise.

So there:
libGL.so.1.2.30500
libGL.so.1 -> libGL.so.1.2.30500
libGL.so -> libGL.so.1


My fingers hurt.
-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

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

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

"Sven M. Hallberg" wrote:
> 
> On Mon, May 21, 2001 at 10:19:40AM -0600, Brian Paul wrote:
> > > 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.
> 
> Those long-established conventions are reflected in the ABI. That's why I
> suggested to create a symlink for the name libGL.so.1. However, that name (as
> I overlooked) conflicts directly with the libtool scheme. See all the way
> below for a solution.
> 
> > IMHO, libtool should have an option to support arbitrary version numbers.
> 
> No it shouldn't. See below.
> 
> > Anyway, we seemed to have made libtools accept the 1.2.0x0y0z convention
> > in recent versions.  Why can't we continue with that?
> 
> The point is that what libtool places there where you want to put a version
> number is not a version number at all. It's a certain code describing the
> interfaces a library exports. That's also the reason why libtool performs that
> check: Using traditional version numbers would result in interface information
> that doesn't make sense. This could lead the dynamic linker to not linking a
> program because the library it finds doesn't appear suitable, although it is.
> 
> I have just played around with libtool a bit because I was curious how it
> would actually go about enforcing the run-time checking of the interfaces.
> I found out that it actually uses (at least on Linux, that is) a _file_
> _name_ scheme very (I'd like to say _exactly_) similar to the version
> numbering scheme used by the OpenGL standard, which is (correct me if I'm
> wrong) to reserve interface changes to major releases, keeping backwards
> compatibility among all releases with the same major number.
> 
> Now what libtool does:
> Out of the interface numbers CURRENT, REVISION and AGE (assuming you know
> their meaning) it computes a version number of the form M.m.r
> like this:
>   M = CURRENT-AGE
>   m = AGE
>   r = REVISION
> The name of the binary becomes:
>   libX.so.M.m.r
> Two symbolic links to it are created:
>   libX.so
>   libX.so.M
> The resemblence to what we're used to is astonishing! However, the final part
> is the one that is important, because it is the one that produces the run-time
> interface checking semantics I was looking for:
> 
> Executables are linked using -soname=libX.so.M !
> 
> That naming convention, combined with the rules for the CURRENT, AGE, and
> REVISION numbers from the libtool documentation have the effect that any
> library which obsoletes some interface ("increment CURRENT, reset AGE") gets a
> new major number while those that keep the old interfaces ("increment CURRENT
> and AGE") retain the same M.
> 
> I don't know, maybe that discovery isn't new to you, but at least I couldn't
> directly derive this from the libtool docs. :}
> 
> Anyways, knowing how libtool naming works and that OpenGL versioning is
> compatible with it we can probably safely reverse the whole thing and
> calculate libtool-style CURRENT and AGE from OpenGL M and m. :)
> 
> With M=1, m=2: CURRENT=3, AGE=2. Finally we can set REVISION to the Mesa
> version number. Libtool doesn't allow leading zeroes, though; it wants nice
> and plain integers. I say we just compute a nice and plain integer for it:
> 
> With Mesa major, minor and release numbers being MM, Mm, and Mr respectively:
>   r = MM * 10^4 + Mm * 10^2 + Mr
> I know this will effectively drop the leading zero, but I think we could
> accept that compromise.
> 
> So there:
> libGL.so.1.2.30500
> libGL.so.1 -> libGL.so.1.2.30500
> libGL.so -> libGL.so.1
> 
> My fingers hurt.

Thanks for the explanation.  I think we're pretty much in agreement actually.
As long as the library's internal SONAME is "libGL.so.1" and we've got the
libGL.so.1 and libGL.so symlinks we shouldn't break linking with existing
applications.

It's a shame that revision = 030500 doesn't directly work.  I could probably
live with revision = 350 as you mentioned in your followup...


> while trying to apply the libtool technique I suggested I found this: libtool
> doesn't accept 30500 as a "nonnegative integer" either. ?:o
> I've tried 350 and it works, so I guess this is just an arbitrary limit on the
> number of digits. Should I ask the libtool people for help?

I'm curious why revision 30500 doesn't work.  Do you know if the revision
is stored as a number or a string?  I'd at least ask the libtool people why
30500 doesn't work.

-Brian

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

[Sven M. H. <pe...@gm...>]

On Mon, May 21, 2001 at 01:54:55PM -0600, Brian Paul wrote:
> Thanks for the explanation.  I think we're pretty much in agreement actually.
> As long as the library's internal SONAME is "libGL.so.1" and we've got the
> libGL.so.1 and libGL.so symlinks we shouldn't break linking with existing
> applications.

We can pass the SONAME explicitly to the linker via libtool (or can't we?) !
Then we can let libtool do pretty much anything it wants with the name.
Additionally, I suggest we do use my idea about reverse-calculating the
version-info, because it doesn't break anything, gives us a fixed way of
knowing the version-info even though we don't control the interface, and it
leaves us with our usual naming conventions at least on Linux and those some
others.


> It's a shame that revision = 030500 doesn't directly work.  I could probably
> live with revision = 350 as you mentioned in your followup...

Right, but 10 minor numbers isn't all too much. We'll likely run short sooner
or later.


> > while trying to apply the libtool technique I suggested I found this: libtool
> > doesn't accept 30500 as a "nonnegative integer" either. ?:o
> > I've tried 350 and it works, so I guess this is just an arbitrary limit on the
> > number of digits. Should I ask the libtool people for help?
> 
> I'm curious why revision 30500 doesn't work.  Do you know if the revision
> is stored as a number or a string?  I'd at least ask the libtool people why
> 30500 doesn't work.

I'll try to look the cause of this up myself and enquire about it with the
libtool guys as soon as we wrap this discussion up.


-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

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

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > I'm curious why revision 30500 doesn't work.  Do you know if the revision
 > is stored as a number or a string?  I'd at least ask the libtool people why
 > 30500 doesn't work.

 because libtool defines non negative as:

    0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]

 i.e., it not only can't start with 0, it can only have three digits.  I
 suspect this has to do with some funny test or expr implementation.  Or
 perhaps they thought three digits would be enough.  Or maybe some sick
 linker uses integers to store this info.
 
 Hmm... funky that '0 | [1-9]' bit...

-- 
Marcelo

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

[Sven M. H. <pe...@gm...>]

On Mon, May 21, 2001 at 11:41:40PM +0200, Marcelo E. Magallon wrote:
> >> Brian Paul <br...@va...> writes:
> 
>  > I'm curious why revision 30500 doesn't work.  Do you know if the revision
>  > is stored as a number or a string?  I'd at least ask the libtool people why
>  > 30500 doesn't work.
> 
>  because libtool defines non negative as:
> 
>     0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]
> 
>  i.e., it not only can't start with 0, it can only have three digits.  I
>  suspect this has to do with some funny test or expr implementation.  Or
>  perhaps they thought three digits would be enough.  Or maybe some sick
>  linker uses integers to store this info.
>  
>  Hmm... funky that '0 | [1-9]' bit...

I'd suspect this was quickly hacked in (explaining the superfluous 0) so they
probably did limit to three digits because they thought it would suffice.

-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

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

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 >   M = CURRENT-AGE
 >   m = AGE
 >   r = REVISION

 This is not generally true (it holds true for Linux, and BSD, IIRC,
 among others)

 > Executables are linked using -soname=libX.so.M !

 The soname is embedded in the library (try readelf -d libfoo | grep
 SONAME on some dynamic library on your system).  The compiler (linker,
 really) reads this information and writes in on the object it produces
 (grep for NEEDED instead of SONAME).  The dynamic linker reads this
 from the object and maps it to a filename.  The dynamic linker can
 perfom other tricks (like loading optimized versions of a library) but
 that's outside the scope of this discussion.

 > I don't know, maybe that discovery isn't new to you, but at least I
 > couldn't directly derive this from the libtool docs. :}

 It's not documented because it's not portable.  Some dynamic linkers
 have more features, some less (IRIX's and AIX's, respectively IIRC).

 > My fingers hurt.

 :-\

-- 
Marcelo

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

[Sven M. H. <pe...@gm...>]

On Mon, May 21, 2001 at 10:05:03PM +0200, Marcelo E. Magallon wrote:
>  >   M = CURRENT-AGE
>  >   m = AGE
>  >   r = REVISION
> 
>  This is not generally true (it holds true for Linux, and BSD, IIRC,
>  among others)

Right. See my other post.


>  > Executables are linked using -soname=libX.so.M !
> 
>  The soname is embedded in the library (try readelf -d libfoo | grep
>  SONAME on some dynamic library on your system).  The compiler (linker,
>  really) reads this information and writes in on the object it produces
>  (grep for NEEDED instead of SONAME).  The dynamic linker reads this
>  from the object and maps it to a filename.  The dynamic linker can
>  perfom other tricks (like loading optimized versions of a library) but
>  that's outside the scope of this discussion.

Ah. Thanks for the explanation.


>  > I don't know, maybe that discovery isn't new to you, but at least I
>  > couldn't directly derive this from the libtool docs. :}
> 
>  It's not documented because it's not portable.  Some dynamic linkers
>  have more features, some less (IRIX's and AIX's, respectively IIRC).

Right, I figured it would be something like that. Nice to know for sure
though (I've personally never seen any other linker than GNU ld on Linux. :/).



-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

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

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > "Sven M. Hallberg" wrote:

 > > - Set a libtool -version-info of 0:MESA_VERSION:0 where
 > >   MESA_VERSION would be 30500 for Mesa 3.5.0.
 > > - 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.

 I missed Sven's post.  Please don't do this.  It breaks binary
 compatibility.  On Linux, among others, the soname would end up being
 libGL.so.0, which means programs compiled with this version of libGL
 would require a libGL.so.0 in order to run.  The symbolic links only
 solve the other problem (compiled with libGL.so.1 and run with
 libGL.so.0 present).  Fixing this once when the library was called
 libMesaGL.so.3 was painful enough...

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

 It has.  Please don't use it, it's a headache. (-release-info).  The
 problem libtool solves doesn't exist in the case of a GL library,
 namely, how do you ensure you aren't breaking binary compatibility on a
 given plataform?  Some dynamic linkers have the concept of library
 versions, some don't.  And those that have it, don't share it with the
 other (not always, at least).  When you use libtool, you place your
 library's versioning in libtool's hands.  Those who try to change
 libtool's idea of "correct versioning" get burned (the lucky ones end
 up with libfoo-1.2.so as library names, the really lucky ones get away
 with it only because the library already has an stable API).  libtool
 solves another problem, namely, how do you compile a library on system
 X with compiler Y?  At this, libtool does a superb job.  But by design,
 the two solutions are coupled.

-- 
Marcelo

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

[Sven M. H. <pe...@gm...>]

On Mon, May 21, 2001 at 09:51:10PM +0200, Marcelo E. Magallon wrote:
>  > > - Set a libtool -version-info of 0:MESA_VERSION:0 where
>  > >   MESA_VERSION would be 30500 for Mesa 3.5.0.
>  > > - 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.
> 
>  I missed Sven's post.  Please don't do this.  It breaks binary
>  compatibility.  On Linux, among others, the soname would end up being
>  libGL.so.0, which means programs compiled with this version of libGL
>  would require a libGL.so.0 in order to run.  The symbolic links only
>  solve the other problem (compiled with libGL.so.1 and run with
>  libGL.so.0 present).  Fixing this once when the library was called
>  libMesaGL.so.3 was painful enough...

Right. Temporarily forgot about the SONAME.


>  > IMHO, libtool should have an option to support arbitrary version numbers.
> 
>  It has.  Please don't use it, it's a headache. (-release-info).  The

It must only do in some brand-new version. 1.4 doesn't seem to know
-release-info.


>  problem libtool solves doesn't exist in the case of a GL library,
>  namely, how do you ensure you aren't breaking binary compatibility on a
>  given plataform?  Some dynamic linkers have the concept of library
>  versions, some don't.  And those that have it, don't share it with the
>  other (not always, at least).  When you use libtool, you place your
>  library's versioning in libtool's hands.  Those who try to change
>  libtool's idea of "correct versioning" get burned (the lucky ones end
>  up with libfoo-1.2.so as library names, the really lucky ones get away
>  with it only because the library already has an stable API).  libtool
>  solves another problem, namely, how do you compile a library on system
>  X with compiler Y?  At this, libtool does a superb job.  But by design,
>  the two solutions are coupled.

This is really a nightmare. How can we have libtool solve the problem of
portable linking for us while still controlling the name of the resulting
library. Anyhow, if other linkers have such different ways of doing things,
how are we supposed to know the correct file name anyhow??


-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

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

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > It must only do in some brand-new version. 1.4 doesn't seem to know
 > -release-info.

 Sorry, memory is playing tricks on me.  -release.

 > This is really a nightmare. How can we have libtool solve the problem
 > of portable linking for us while still controlling the name of the
 > resulting library. Anyhow, if other linkers have such different ways
 > of doing things, how are we supposed to know the correct file name
 > anyhow??

 That's the whole point: you don't.  That's the reason for libtoo's
 libfoo.la files.

 The two things are coupled because "baptizing" the library is part of
 the linking process.  Off the top of my head, MIPSpro does this using a
 linker program and a -soname flag while GNU CC does it using the
 compiler (the frontend really, which ends up calling the GNU linker)
 and a "-Wl,-soname," flag (for GNU CC it does make a difference if you
 use the linker or the gcc frontend).

 The solution you propose with CURRENT:AGE:REVISION works for Linux and
 other systems, but it's not portable (HP-UX is a good example, barring
 the fact that dynamic libraries are called libfoo.sl instead of
 libfoo.so, you'll note there aren't any libfoo.sl.1.2, only libfoo.1).
 There's no way to get the "correct" version number on every
 architecture, that's why libtool doesn't offer that possibility.

 Which reminds me of something else: inter-library dependencies, which
 libtool does support on systems that support it.  It means, for
 example, that libGL.so.1 is linked against libpthread.so.0,
 libXext.so.6, libX11.so.6 and libdl.so.2.  That is, the library itself
 uses functions from those libraries.  This is the difference between:

 $ cc -o gears gears.c -lglut

 and

 $ cc -o gears gears.c -lglut -lGL -lGLU -L/usr/X11R6/lib -lXmu -lXext \
 -lXi -lX11 -lm

 (I think those all all) in this case libglut contains "NEEDED" entries
 for all those libraries.  All you need to change is:

 $ cc -o libfoo.so.1.2.3 foo.o bar.o baz.o -Wl,-shared,libfoo.so.1

 to

 $ cc -o libfoo.so.1.2.3 foo.o bar.o baz.o -Wl,-shared,libfoo.so.1 \
 -lfi -lfai -lfo

 (but again, this varies from compiler to compiler and that's why
 libtool performs some magick when it sees something like this)

-- 
Marcelo

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

[Sven M. H. <pe...@gm...>]

On Mon, May 21, 2001 at 11:33:32PM +0200, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > It must only do in some brand-new version. 1.4 doesn't seem to know
>  > -release-info.
> 
>  Sorry, memory is playing tricks on me.  -release.

Oh, my accidental use of -release was the whole starting point of discussion,
so I know that one. :)


>  > This is really a nightmare. How can we have libtool solve the problem
>  > of portable linking for us while still controlling the name of the
>  > resulting library. Anyhow, if other linkers have such different ways
>  > of doing things, how are we supposed to know the correct file name
>  > anyhow??
> 
>  That's the whole point: you don't.  That's the reason for libtoo's
>  libfoo.la files.

Then, if we don't know the correct filename (except in special cases where
there is something like an ABI) we can let libtool decide. After all it's its
job! If we stumble across a system with an ABI we might be violating, we can
still incorporate a special-case treatment.


>  The two things are coupled because "baptizing" the library is part of
>  the linking process.  Off the top of my head, MIPSpro does this using a
>  linker program and a -soname flag while GNU CC does it using the
>  compiler (the frontend really, which ends up calling the GNU linker)
>  and a "-Wl,-soname," flag (for GNU CC it does make a difference if you
>  use the linker or the gcc frontend).

I see.


>  The solution you propose with CURRENT:AGE:REVISION works for Linux and
>  other systems, but it's not portable (HP-UX is a good example, barring
>  the fact that dynamic libraries are called libfoo.sl instead of
>  libfoo.so, you'll note there aren't any libfoo.sl.1.2, only libfoo.1).
>  There's no way to get the "correct" version number on every
>  architecture, that's why libtool doesn't offer that possibility.

Exactly. So we should really leave the naming to libtool. As hinted in my
other post, we should use the CURRENT/AGE reverse calculation only as a means
to produce valid CURRENT/AGE from OpenGL standard version numbers, not to
influence the library naming at all.

As for ABI-compliance:
On Linux, for example, we use the configure script to check that the linker
supports the -soname flag and use that to set the correct SONAME on the library
object. Also we include an install-hook that checks whether libtool created a
library with the correct name (libGL.so.1 - the SONAME). If it didn't, it
creates a link to that which was created.

Here's the pseudo-code for the install-hook, do you think this would be OK to
do on systems identified as Linux?

install-hook:
        if test `find .libs/ -name libGL.so.1 | grep -c libGL.so.1` != 1; then
          libfile=`find .libs/* -not -type l -not -name '*.lai'`
          if test 'echo $libfile | grep -c $libfile` = 1; then
            ln -s @libdir@/$libfile @libdir@/libGL.so.1
          else
            echo "ABI conformance error! Libtool created a library whose name"
            echo "does not conform to the Linux OpenGL ABI and we were unable"
            echo "to find the name it did use. Therefore a workaround is"
            echo "impossible."
            echo "*** Your Mesa3D installation does NOT conform to the Linux"
            echo "*** OpenGL ABI!
          fi
        fi
uninstall-hook:
        rm -f @libdir@/libGL.so.1 # just in case


>  Which reminds me of something else: inter-library dependencies, which
>  libtool does support on systems that support it.  It means, for
>  example, that libGL.so.1 is linked against libpthread.so.0,
>  libXext.so.6, libX11.so.6 and libdl.so.2.  That is, the library itself
>  uses functions from those libraries.  This is the difference between:
> 
>  $ cc -o gears gears.c -lglut
> 
>  and
> 
>  $ cc -o gears gears.c -lglut -lGL -lGLU -L/usr/X11R6/lib -lXmu -lXext \
>  -lXi -lX11 -lm
> 
>  (I think those all all) in this case libglut contains "NEEDED" entries
>  for all those libraries.  All you need to change is:

Ah! I've always wondered about how this is actually accomplished! :)
NEEDED-entries... Thanks.


>  $ cc -o libfoo.so.1.2.3 foo.o bar.o baz.o -Wl,-shared,libfoo.so.1
> 
>  to
> 
>  $ cc -o libfoo.so.1.2.3 foo.o bar.o baz.o -Wl,-shared,libfoo.so.1 \
>  -lfi -lfai -lfo
> 
>  (but again, this varies from compiler to compiler and that's why
>  libtool performs some magick when it sees something like this)

So you mean, we should include the library depedencies in our library objects?


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 ]

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

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > Then, if we don't know the correct filename (except in special cases
 > where there is something like an ABI) we can let libtool decide.
 > After all it's its job! If we stumble across a system with an ABI we
 > might be violating, we can still incorporate a special-case
 > treatment.

 Yes.  My guess is that each (Unix-like) vendor has (an|their own) ABI
 for OpenGL.  Linux just happens to have one that's used by more than
 one group.  A quick look arround here indicates that HP-UX's libGL is
 called libGL.2, IRIX's seems to be called libGL.so with a "MIPS
 version" of "sgi1.0" (I have never understood SGI's policy regarding
 SONAMEs, but I've never seen it break, so I guess it's ok).  The other
 Unix flavors I have access to don't have the vendor's libGL installed
 on them. 

 > Here's the pseudo-code for the install-hook, do you think this would
 > be OK to do on systems identified as Linux?

 Hmmm...  the whole ABI bussiness is about the soname *in* the library
 file.  libtool happyly ignores any -Wl,-soname,libfoo.so.1 you pass to
 it (because it's not portable).

 >         if test `find .libs/ -name libGL.so.1 | grep -c libGL.so.1` != 1; then
 if there's exactly one file named libGL.so.1 ...
 >           libfile=`find .libs/* -not -type l -not -name '*.lai'`
 look for the library files ... (note there are likely two of these, one
 libGL.so.x.y.z and one libGL.a -- you *want* the libGL.a, too)
 >           if test 'echo $libfile | grep -c $libfile` = 1; then
 I got lost here.  If there's exactly one shared library?
 >             ln -s @libdir@/$libfile @libdir@/libGL.so.1
 link libGL.so.1 to this
 >           else
 else there's a problem.

 Like I said, what's important is the SONAME contained in the library,
 what this file is called is not important.  Like this:

 soname=`readelf -d $libfile | sed -ne '/SONAME/ s/.*\[\(.*\)\]/\1/p'`
 if test $soname != libGL.so.1
     echo There's a problem ...
     exit 1
 else
     # Asuming libfile is something like libGL.so.1.2.350 (and not
     # /some/dir/.libs/libGL.so.1.2.350)
     ln -s $libfile @libdir@/libGL.so.1
 fi

 (objdump and readelf are both part of binutils, so on Linux it's safe
 to asume they are present.  I just happen to like readelf better)

 > So you mean, we should include the library depedencies in our library
 > objects?

 If possible, yes.  It makes life much simpler.  :-)

 BTW, I tried -version-info 3:350:2 on IRIX...  not good... the linker
 exits with a bus error.  Gotta love the MIPSpro tool chain...

-- 
Marcelo

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

[Sven M. H. <pe...@gm...>]

On Tue, May 22, 2001 at 01:12:39PM +0200, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > Then, if we don't know the correct filename (except in special cases
>  > where there is something like an ABI) we can let libtool decide.
>  > After all it's its job! If we stumble across a system with an ABI we
>  > might be violating, we can still incorporate a special-case
>  > treatment.
> 
>  Yes.  My guess is that each (Unix-like) vendor has (an|their own) ABI
>  for OpenGL.  Linux just happens to have one that's used by more than
>  one group.  A quick look arround here indicates that HP-UX's libGL is
>  called libGL.2, IRIX's seems to be called libGL.so with a "MIPS
>  version" of "sgi1.0" (I have never understood SGI's policy regarding
>  SONAMEs, but I've never seen it break, so I guess it's ok).  The other
>  Unix flavors I have access to don't have the vendor's libGL installed
>  on them. 

OK. So we let libtool do its work and (constructively) interfere with it only
where the necessity pops up, right?


>  > Here's the pseudo-code for the install-hook, do you think this would
>  > be OK to do on systems identified as Linux?
> 
>  Hmmm...  the whole ABI bussiness is about the soname *in* the library
>  file.  libtool happyly ignores any -Wl,-soname,libfoo.so.1 you pass to
>  it (because it's not portable).

Oh, I'll try it, too.


>  >         if test `find .libs/ -name libGL.so.1 | grep -c libGL.so.1` != 1; then
>  if there's exactly one file named libGL.so.1 ...
If there's not exactly one.
>  >           libfile=`find .libs/* -not -type l -not -name '*.lai'`
>  look for the library files ... (note there are likely two of these, one
>  libGL.so.x.y.z and one libGL.a -- you *want* the libGL.a, too)
Oh, right. Maybe we should just scrap this whole thing, assuming libtool does
it right.
>  >           if test 'echo $libfile | grep -c $libfile` = 1; then
>  I got lost here.  If there's exactly one shared library?
Oh, this is of course bull. echo $libfile | grep -c '*' = 1 would be correct.
Basically meant as a line count (Is wc -l portable?).
>  >             ln -s @libdir@/$libfile @libdir@/libGL.so.1
>  link libGL.so.1 to this
>  >           else
>  else there's a problem.


>  Like I said, what's important is the SONAME contained in the library,
>  what this file is called is not important.  Like this:

Really?? I thought it was like this:
 SONAME of library X = Y.
 compile executable Z with -lX
  -> linker puts SONAME(X)=Y to NEEDED(Z)
 execute Z
  -> linker looks up library of _name_ Y.
     If lib Y doesn't exist, linker fails.

Is it different?


>  soname=`readelf -d $libfile | sed -ne '/SONAME/ s/.*\[\(.*\)\]/\1/p'`
>  if test $soname != libGL.so.1
>      echo There's a problem ...
>      exit 1
>  else
>      # Asuming libfile is something like libGL.so.1.2.350 (and not
>      # /some/dir/.libs/libGL.so.1.2.350)
>      ln -s $libfile @libdir@/libGL.so.1
>  fi
> 
>  (objdump and readelf are both part of binutils, so on Linux it's safe
>  to asume they are present.  I just happen to like readelf better)

OK.


>  > So you mean, we should include the library depedencies in our library
>  > objects?
> 
>  If possible, yes.  It makes life much simpler.  :-)

Hm. look at this:
--- 8< ---
pesco@crest:~/cvswork/Mesa/src/.libs$ ldd libGL.so
        libvga.so.1 => /usr/lib/libvga.so.1 (0x401de000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40235000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4023e000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40254000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40269000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40278000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40280000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4035b000)
        libc.so.6 => /lib/libc.so.6 (0x40371000)
        libm.so.6 => /lib/libm.so.6 (0x40483000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404a5000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
pesco@crest:~/cvswork/Mesa/si-glu/.libs$ ldd libGLU.so
        libc.so.6 => /lib/libc.so.6 (0x400b5000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
--- >8 ---

libGL already gets these dependencies from the various convenience libs.
Can anyone see whether there are any missing? Since I built the si-glu
Makefile.am's I'll just add -lGL there, right?


>  BTW, I tried -version-info 3:350:2 on IRIX...  not good... the linker
>  exits with a bus error.  Gotta love the MIPSpro tool chain...

Ugh. Do you have any indication why that fails? Maybe it doesn't like the high
REVISION number?


Greetings,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

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

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > OK. So we let libtool do its work and (constructively) interfere with
 > it only where the necessity pops up, right?

 Yes, I guess that's the safest solution.
 
 > >  Like I said, what's important is the SONAME contained in the library,
 > >  what this file is called is not important.  Like this:
 > 
 > Really?? I thought it was like this:
 >  SONAME of library X = Y.
 >  compile executable Z with -lX
 >   -> linker puts SONAME(X)=Y to NEEDED(Z)
 >  execute Z
 >   -> linker looks up library of _name_ Y.
 >      If lib Y doesn't exist, linker fails.
 > 
 > Is it different?

 No, it's like that.  I meant that you have to check that the SONAME is
 set right and that there's a link SONAME(lib) ->
 whatever_libtool_called_it (e.g. libGL.so.1 -> libGL.1.2.350) and
 another one PUBLIC_NAME(lib) -> whatever_libtool_called_it (e.g.,
 libGL.so -> libGL.1.2.350)
 
 > libGL already gets these dependencies from the various convenience libs.
 > Can anyone see whether there are any missing? Since I built the si-glu
 > Makefile.am's I'll just add -lGL there, right?

 Funny that it doesn't list libstdc++, but appart from libGL, no, it
 doesn't need anything else ...

 > Ugh. Do you have any indication why that fails? Maybe it doesn't like
 > the high REVISION number?

 Libtool tries to pass something like 'sgi350.0:sgi349.0:...:sgi2.0:sgi1.0'
 to the linker, and the linker doesn't seem to like that and terminates
 with a bus error...

-- 
Marcelo

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

[Sven M. H. <pe...@gm...>]

On Tue, May 22, 2001 at 09:19:53PM +0200, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pe...@gm...> writes:
> 
>  > OK. So we let libtool do its work and (constructively) interfere with
>  > it only where the necessity pops up, right?
> 
>  Yes, I guess that's the safest solution.

Alright. Brian, is this OK with you?


>  > >  Like I said, what's important is the SONAME contained in the library,
>  > >  what this file is called is not important.  Like this:
>  > 
>  > Really?? I thought it was like this:
>  >  SONAME of library X = Y.
>  >  compile executable Z with -lX
>  >   -> linker puts SONAME(X)=Y to NEEDED(Z)
>  >  execute Z
>  >   -> linker looks up library of _name_ Y.
>  >      If lib Y doesn't exist, linker fails.
>  > 
>  > Is it different?
> 
>  No, it's like that.  I meant that you have to check that the SONAME is
>  set right and that there's a link SONAME(lib) ->
>  whatever_libtool_called_it (e.g. libGL.so.1 -> libGL.1.2.350) and
>  another one PUBLIC_NAME(lib) -> whatever_libtool_called_it (e.g.,
>  libGL.so -> libGL.1.2.350)

Right. Since we can't influence the SONAME directly, we don't have any other
option than to check whether libtool did what we wanted and issue an error
message otherwise.


>  > libGL already gets these dependencies from the various convenience libs.
>  > Can anyone see whether there are any missing? Since I built the si-glu
>  > Makefile.am's I'll just add -lGL there, right?
> 
>  Funny that it doesn't list libstdc++, but appart from libGL, no, it
>  doesn't need anything else ...

I don't think GLU uses the STL.


>  > Ugh. Do you have any indication why that fails? Maybe it doesn't like
>  > the high REVISION number?
> 
>  Libtool tries to pass something like 'sgi350.0:sgi349.0:...:sgi2.0:sgi1.0'
>  to the linker, and the linker doesn't seem to like that and terminates
>  with a bus error...

Did you try it with a lower revision number? What does a "bus error" mean
exactly, do you know? I don't.


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 ]