Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Sep 1998 15:50:28 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Joe Abley <jabley@clear.co.nz>
Cc:        David Holland <dholland@cs.toronto.edu>, freebsd@xaa.iae.nl, freebsd-current@FreeBSD.ORG
Subject:   Re: ELF ldconfig 
Message-ID:  <199809200750.PAA17687@spinner.netplex.com.au>
In-Reply-To: Your message of "Sun, 20 Sep 1998 17:02:57 %2B1200." <19980920170257.B9422@clear.co.nz> 

next in thread | previous in thread | raw e-mail | index | archive | help
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 <jabley@clear.co.nz>      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



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