On Mon, May 21, 2001 at 11:33:32PM +0200, Marcelo E. Magallon wrote:
> >> "Sven M. Hallberg" <pesco@...> 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@... @libdir@...
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@... # 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 ]
|