On Mon, 15 Apr 2002 18:12:06 -0600
Collins <[EMAIL PROTECTED]> wrote:
> On Sat, 13 Apr 2002 20:22:21 -0400 Kurt Wall <[EMAIL PROTECTED]>
> wrote:> Scribbling feverishly on April 13, Pam R managed to emit:
> >
> > [whack]
> >
> > > Don't forget the linux motto: "Release early, release often, and
> > > fsck the customer"
> >
> > I don't use software that evinces such an attitude, at least the
> > third element. I hope that was written with tongue firmly in
> > cheek...
> >
>
> I think that attitude is not really totally written tongue in cheek,
> and it applies to the whole linus-gnu-other supporting products
> environment. We can all remember the glibc updates that broke almost
> every system they touched. There have been a few linux gotchas in the
> 2.4.x supposedly stable release. Now there's a new one with libpng.
>
> I'm on gentoo which puts me a little closer to the bleeding edge than
> I'd like to be. gentoo has a wonderful feature called "emerge
> --update world" which looks through the portage catalogue and attempts
> to apply everything that offers a newer version in the right sequence
> to satisfy dependancies. This works like a charm, until the latest
> libpng upgrade came along, which broke every X program that uses
> libpng.
Sloppy use of the linker to make libpng. One option to ld is the name that
the library should have INTERNALLY. That is, the name that will be placed in
programs that link with the library. From 'man ld':
-soname name
When creating an ELF shared object, set the internal DT_SONAME field to
the specified name. When an executable is linked with a
shared object which has a DT_SONAME field, then when the
executable is run the dynamic linker will attempt to load the shared
object specified by the DT_SONAME field rather than the using the
file name given to the linker.
Why is this useful?
Make a library called libpng.so.1.0. Have 'libpng.so.1.0' be the name put
in the library for later inclusion in all programs that link with this
library (above option).
Install libpng.so.1.0 on your system. Make a symbolic link to libpng.so
Then, all programs that link with -lpng will, in fact, have 'libpng.so.1.0'
(the library's internal name) recorded as the file to load. Users of libpng
need know nothing of this. It is private to libpng.
Then, do a library update. Make a new libpng.so.1.2. Hey, even link
libpng.so to this new file. Don't delete the old libpng.so.1.0. Old
programs will still use it. New programs will use the new one because
of the symlink (and probably because of new include files).
Will you break all the old linked programs? NO! Because they use the
internal name of libpng when they were linked, which was libpng.so.1.0.
They know nothing of libpng,so (even though that was the disk file name they
linked against) or of libpng.so.1.2.
We have used this for years. It is also supported with UnixWare's ld.
I really do not know why makers of librarys don't use this more often. They
name the libraries with all these version numbers, but they fail to take
advantage of it with the -soname linker option. Especially when the use is
totally self contained in the library. Library users need not even know it
is happening.
--
+============================+===============================+
| Roger Oberholtzer | E-mail: [EMAIL PROTECTED] |
| OPQ Systems AB | WWW: http://www.opq.se/ |
| Erik Dahlbergsgatan 41-43 | Phone: Int + 46 8 314223 |
| 115 32 Stockholm | Mobile: Int + 46 733 621657 |
| Sweden | Fax: Int + 46 8 302602 |
+============================+===============================+
_______________________________________________
Linux-users mailing list - http://linux-sxs.org/mailman/listinfo/linux-users
Subscribe/Unsubscribe info, Archives,and Digests are located at the above URL.
