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>