Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 01 Oct 1998 10:56:40 -0400
From:      "Kaleb S. KEITHLEY" <kaleb@ics.com>
To:        devel@XFree86.org, hackers@FreeBSD.ORG
Subject:   Re: ELF shared library "revision" numbers
Message-ID:  <36139828.2F3833FD@ics.com>
References:  <19980926142659.E22169@rf900.physics.usyd.edu.au> <36123E72.750CF4BB@ics.com> <19981001120007.C25329@rf900.physics.usyd.edu.au>

next in thread | previous in thread | raw e-mail | index | archive | help
David Dawes wrote:
>  Kaleb wrote:
> >The X11 sample implementation uses the strings it does to, A) make them easy
> >to distinguish from those that Sun, SGI, Unixware, etc., ship; and B) to
> >make them easy to distinguish which libraries are built from which
> >releases; and C) to informally document when new functionality was added
> >to a particular library. If there was no change in a library (save bug
> >fixes) between releases, then the SONAME wasn't changed -- that's why
> >libXt is still libXt.so.6.0, but libXext is libXext.so.6.4. Hmmh, libXt
> >probably should have changed in R6.4 because of the easy resource config
> >stuff that was added. Sigh.
> 
> It doesn't follow your "Unless the ABI changes in an incompatible way,
> you don't change the SONAME" statement above for your definition of
> "incompatible".  

That's the ELF definition of incompatible, not mine.

> The definition of "incompatible" that FreeBSD has chosen
> includes adding new functions while keeping all the previous interfaces
> unchanged.

Ugh. That's bad. That's going to force people to keep old libraries
around for old programs, and /usr/lib is going to suffer from bloat.
Either that or it's going to force people to go manually dink their
/usr/lib to create symlinks if they want to get rid of old libraries.
(Yeah, yeah, disk is cheap.)

At the risk of using those hated words: that's not how everyone else
does it. I'm going to use them anyway (and I'm cc-ing the
freebsd-hackers list). There are probably more reasons than those I've
already mentioned, why everyone else does it the way they do. I hope
they'll rethink.

Bumping the SONAME/version when you add APIs doesn't buy you anything.

> >Not limited to FreeBSD, but how do you avoid conflicting with Metro Link
> >or XiGraphics libraries? It's true that this can be solved with an RPATH
> >recorded in  binaries, but I'd wager that in some sense Metro Link, Xi
> >Graphics, and XFree86 all want their X libraries to be THE libraries and
> >have them installed in /usr/lib. An unambiguous version-naming scheme
> >would allow everyone to put their libraries in /usr/lib and thus not
> >require that binaries have an RPATH or that the user set his or her
> >LD_LIBRARY_PATH to find the right set of libraries.
> 
> XFree86 wants the libraries installed in /usr/X11R6/lib.  Our aim has been
> to have our libraries compatible with the SI versions of the same name
> in the sense that all interfaces present in the SI versions are present
> and compatible in ours.

The sample implementation needed to be nice on systems like Suns, HPs,
and SGIs, where the vendor had X11 installed in /usr/lib. On Linux and
FreeBSD, where you're not competing with the vendor's X11, I think it'd
be nicer to install in /usr/lib so that programs don't need an RPATH or
LD_LIBRARY_PATH to find their libraries. (Here comes those hated words
again) That's why everyone else does it that way.

> >> It doesn't clobber
> >> previous versions either, but means that older apps will either need
> >> the old libXext.so.6 installed, or a link added to the new one.
> >
> >What older apps on a new ELF system? Don't old a.out binaries need the
> >old a.out libraries. In which case if they're really old, they use the
> >ld.so.cache, and if they're only a little old, FreeBSD 2.2.x has had an
> >extended a.out format with RPATH.
> 
> For FreeBSD/ELF, the a.out libraries get moved to /usr/X11R6/aout/ and
> the runtime loader (with help from ldconfig?) takes care of finding them.

My point exactly. You don't have to worry about clobbering anything.

> Another aspect of FreeBSD's decision about how to handle all of their
> ports is that when the ELF version gets bumped the a.out version of the
> port (for FreeBSD 2.2.x) also has its major rev bumped and the minor rev
> clamped at zero.  I don't personally agree with the way they've handled
> this.  However, I don't want to see different (incompatible) sets of
> XFree86 binaries for FreeBSD/ELF.

So why don't you do it right and get them to fix their port? Or do you
want to live with brokenness for ever? FreeBSD 3.0 is still only in
beta.

-- 
Kaleb

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36139828.2F3833FD>