On Wed, 4 Dec 1996, Jonathan Stone wrote:

.. This is _precisely_ the question I thought I asked for feed-back on,
.. here: whether it's better to do what other NetBSD ports do, and make
.. ``pic'' code the default -- as the snapshot does -- or to build
.. non-PIC static libraries (libc.a).  The problem is linking a mixture
.. of PIC and non-PIC .o files together.  If you try, the linker produces
.. error messages saying it can't do this, though the resulting binaries
.. may actually work.
Plus the confusions about pic vs. non-pic versions of crt0.o ... ;)
.. 
.. The cost of having non-PIC libc.a is that users who _want_ to build
.. statically-linked binaries now have to give extra, nonstandard
.. arguments when compiling their own .o files.
This includes NetBSD itself, e.g. /usr/src/{bin,libexec,sbin}.
.. 
.. So, if anyone has an opinion on which way to go, now is the
.. time to express it :).
.. 
Now that I understand more of it, I can start thinking of having an
opinion :)
Anyway, I did experience all those linker messages many times during my
experiments. I don't know the number of times that I recovered by
installing a somewhat stripped-down copy of comp12...
Before thinking too much, I guess that we'll end up accepting the 
snapshot approach using pic .o's all over and accepting that they
result in larger statically linked executables. I may have to re-
partition to get a larger root partition (you are not alone, Jonathan).

I really don't like to force programmers (in particular those implementing
portable packages) to require non-standard compiler directives just to
compile non-dynamically linked executables. In particular I don't like
to do that for some, but not for all, NetBSD ports.

.. 
.. 
.. [Problems with ld.so and  shared-lib names: libtelnet.so/libtelnet.so.1.0]
.. 
.. The ld.so in the snapshot is, AFAIK, an OpenBSD snapshot, derived in
.. turn from the i386 Linux (GNU) ELF ld.so.  The library naming
.. conventions used by this ld.so, and it ldconfig, are a bad fit for the
.. NetBSD library naming conventions.  Yes, you need all those symlinks.
.. 
.. my hope here is that someone will port the ELF ld.so being used on
.. NetBSD/Alpha, which is derived from FreeBSD's ld.so and is a much
.. better fit for NetBSD.
Thank you for the information.
.. 
.. [partial ldd port]
.. 
.. hey, that's neat, thanks. Don't forget to send a PR or patches
.. when you're done.
Well, what I did is a gross hack, not worth PR-ing..... I just removed
a few tests for a.out executables. To make it work, I (or someone else)
should apply alternative tests for recognizing elf dynamicly linked
executables. Anyway all that ldd does is to check parameters and that
the arguments denote dynamically linked executables. It then forks
ld.so to do the shared library magic controlled by a couple of
environment variables to print the libraries used and to prevent
the actual execution of the programs.
The parameter validation is in fact needed, because the ld.so forking will
actually end up executing the file if it is not dynamically linked.
.. 
.. --Jonathan
.. 
.. 
 - Erik