[ On Tuesday, October 16, 2001 at 21:12:46 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: stdio FILE extension
>
> No, it's not a bug -- ELF doesn't have shlib verions...

Ah ha -- I understand.  shades of DLLs showing through....

> it has SONAME,
> which can be used to implement versions.

Hmmmm.... well then it's a hack -- I wouldn't call that much of an
implementation of versioning support if that's all there really is....

The more I learn the more I think libc's "major" number needs to be
bumped with every major OS release, even if there's no under

>  > In any case there's still the /emul way of doing things....
> 
> That requires a new "magic" for the binary and support in the kernel

Well yes, I realise that.  (unless of course there's some other place
for a version identifier in the ELF header that could be used....)

> for something which has nothing to do with the kernel.

Oh, but it does -- the reason for the magic renames and such is so that
the kernel ABI can change without changing the libc ABI.  How much more
related can you get?

If the kernel wants to simultaneously support a prior ABI variation then
the obvious way to do that is with the /emul feature.

The problem with trying to keep the libc ABI static is that it's not
really doing much w.r.t. overall application ABI portability.  Any
application that uses a system call with no better defined libc ABI will
still have to be re-compiled anyway.

Binary compatability is a fine and necessary thing for some purposes,
but it's not something that any OS vendor should ever have to promise
accross multiple "major" releases.  Certainly you need stepping stones
to manage upgrade bootstrapping, but that's exactly the kind of thing
that's best done with something like /emul because then your covered on
all the bases with no chance for confusion with anything using an ABI
not fronted by a dynamically linked library interface.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>