[ On , September 28, 2000 at 17:50:52 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: CVS commit: pkgsrc
>
> Me, i'd rather have what I asked the linker to do -- include a
> specific set of libraries -- deterministically cause those libraries
> to be included.

The problem is that this has never in the past been the way a Unix
linker and loader works and indeed it is still not the way the NetBSD ld
behaves if you tell it to create a static binary.  In fact it's self-
inconsistent with the way NetBSD's dynamic linking works in relation to
the statically linked portion of a dynamic binary!

The worst part though is that NetBSD and Solaris (and presumably other
similarly "modern" systems) are the only ones where dynamic loaders have
taken on this behaviour.  Even SunOS-4's dynamic loader did not work
this way.

This "feature" is really just a solution looking for problems, but all
I've ever seen it find are scenarios which cause bugs.  I.e. real
software which breaks due to "hidden" side-effects in the build.
There's more than once when I've been faced with an arcane build system
where adding "-static" was the only viable solution.

Please don't "blame" this on ELF either.  ELF may be what makes it
possible, but it's certainly not necessary because of ELF!  NetBSD a.out
shared libraries suffer the same mis-feature.

I realise there may not be any simple fixes to the actual `ld' that
NetBSD uses -- I've never been inside it, but conceptually it's not a
hard problem to solve since the necessary mechanisms already exist and
work just fine for static binaries.

Now if you said this about kernel-level shared libraries ala SysV then I
might agree -- they are already very different critters and act in the
system more like dependent binaries than libraries.

-- 
							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>