From owner-freebsd-current Sun Sep 20 00:54:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA09470 for freebsd-current-outgoing; Sun, 20 Sep 1998 00:54:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA09449 for ; Sun, 20 Sep 1998 00:54:02 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id PAA17687; Sun, 20 Sep 1998 15:50:29 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199809200750.PAA17687@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Joe Abley cc: David Holland , freebsd@xaa.iae.nl, freebsd-current@FreeBSD.ORG Subject: Re: ELF ldconfig In-reply-to: Your message of "Sun, 20 Sep 1998 17:02:57 +1200." <19980920170257.B9422@clear.co.nz> Date: Sun, 20 Sep 1998 15:50:28 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Abley wrote: > On Sun, Sep 20, 1998 at 12:00:55AM -0400, David Holland wrote: > > > That was my concern. Surely there must come a time when two versions of > > > a shared library exist (with identical major version numbers), and an > > > application requires to be dynamically linked to the older of the two > > > because of some incompatibility with the newer library? > > > > Standard ELF doesn't allow this, or support minor version numbers. a.out doesn't allow this either. If you have libc.so.3.0 and libc.so.3.1 on the system, *everything* will use libc.so.3.1, regardless of which one it was linked against originally. ELF doesn't loose anthing important there. With regard to minor numbers, under a.out you had this situation where adding a symbol to a library required (by policy) a minor version bump. What this caused, was that all libraries linked against the new library would cause an annoying warning when run against an older library on a different system - even though it still ran fine. *if* the new program used the new symbol, you got the version warning and then an undefined symbol error. With our elf implementation as it stands at present, there is no minor version checking. It either links or it doesn't. As far as I'm concerned, that's no great loss, and depending on how you think about it, it could be considered an improvement. However, once we blow away a.out support in the libs, we can do nice things like symbol versioning. This is *really* nice because you do versioning on a symbol-by-symbol basis rather than at the entire library level. Ie: it will be possible to make significant changes to the library interface and it may be more practical to provide a backwards compatable interface to the occasional function to avoid the need for a major bump. Obviously there is a tradeoff to consider as you accumulate cruft as you go, but it saves the need for a major bump in response to a tiny incompatable change. For example, suppose msync() had 2 args and was changed to have 3 args. It would normally require a major bump normally, but with versioning we could do this (I'm not sure of the exact syntax, but you get the idea): __symversion(msync, msync@LIBC_4_0) int msync(arg1, arg2, arg3) { .... } int msync@LIBC_3_0(arg1, arg2) { return msync(arg1, arg2, 0); } This means that a program linked against a call to msync() would actually link against msync@LIBC_4_0(). Older programs would be linked against the msync@LIBC_3_0() name and would continue to run. You could put __warn_references() on the old name after a while so you could cause warnings on binaries using the old interface etc. All of this is hidden within the library itself. It's not something that the includes have to be aware of. Linux is getting into this in a big way within glibc it seems. Not that that itself means that we should, but it (in the right situation) can pay off. I think I saw that they (so far) have used it to emulate an old stdio (incompatable) implementation without a major version bump. The other main reaosn why ELF dropped the minor version number is for efficiency. Without it, you don't *need* to do expensive directory scanning or have it cached via ldconfig etc. The library file is either there or it isn't. That's why there is no ELF ld.so.cache. > > Even worse things happen when you have two builds of (say) > > libslang.so.1 that were compiled against different libcs and are thus > > not interchangeable... > > So remind me why ELF is a good idea? :) a.out can't do this either. We would have to bump all major library numbers in a.out because things like the errno -> __error() change in libc and libtermcap calling issetugid() etc. Don't forget, at the moment all that the ELF support is being used for is to emulate a.out. We have not yet begun to use the "good stuff". > -- > Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 > Network Architect, CLEAR Net http://www.clear.net.nz/ Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message