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 ]