From owner-freebsd-hackers Thu Oct 1 07:59:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA00863 for freebsd-hackers-outgoing; Thu, 1 Oct 1998 07:59:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ics.com (ics.com [140.186.40.192]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00858 for ; Thu, 1 Oct 1998 07:59:26 -0700 (PDT) (envelope-from kaleb@ics.com) Received: from ics.com (sunoco.ics.com [140.186.40.142]) by ics.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id KAA14244; Thu, 1 Oct 1998 10:56:40 -0400 (EDT) Message-ID: <36139828.2F3833FD@ics.com> Date: Thu, 01 Oct 1998 10:56:40 -0400 From: "Kaleb S. KEITHLEY" Organization: Integrated Computer Solutions X-Mailer: Mozilla 4.5b2 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: devel@XFree86.org, hackers@FreeBSD.ORG Subject: Re: ELF shared library "revision" numbers References: <19980926142659.E22169@rf900.physics.usyd.edu.au> <36123E72.750CF4BB@ics.com> <19981001120007.C25329@rf900.physics.usyd.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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