[ On Sunday, March 18, 2001 at 10:20:35 (-0800), Jason R Thorpe wrote: ]
> Subject: Re: why /bin and /sbin static
>
> Uh -- it's mostly an issue to 3rd-party interoperability.  We cannot
> easily bump the major number of 3rd-party shared libraries, therefore
> we use the symbol renaming trick (which, incidentally, Solaris also
> uses...)

Well, yeah, but how much does that really matter in the real world?

How many actual instances of vendors of third-party non-source binary
shared libraries are there?  I've never encountered any in my admittedly
narrow experience with using NetBSD in production environments.  The
only decent example I know of is Motif, but I've never used it and I'll
bet it's not widely used either.  I'll also bet they re-compile it for
every full NetBSD release anyway.  From the "Gallery" pages I can guess
that the Raven SSL module might have some dependencies, as might the OSS
stuff.  Still in all those examples there are probably many other good
reasons for the vendor to re-compile and re-release new binaries for
every NetBSD major release anyway.

Most non-source third-party software I've ever run works under emulation
anyway, and now we even have a.out emulation for NetBSD.  Why not just
use emulation for all levels of backward compatability?

Yes I know other systems use the symbol renaming trick, and within
itself it's a pretty neat hack.  However NetBSD isn't a binary-only
system -- all other vendors have access to source too, as do all users
who want it.  There's really no excuse for the current scenario -- it's
as if some NetBSD users have become too accustomed to the way
traditional OS vendors do things in non-open-source environments and
they're simply following rote and even using them as "bad" examples!  :-)

How much extra cost is there to keeping all the old crud in the kernel
and libraries (I'm betting without really looking that it's not
insignificant)?  How easy/hard would it be for an embedded systems
developer (who would be concerned about those costs) to actually
eliminate all the old interfaces in the kernel and libraries and to undo
the renaming tricks (quite hard from what I can see)?

The only real need I can see for the renaming trick in NetBSD is for
when a binary interface really must be changed in a patch release.

-- 
							Greg A. Woods

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