alpha and mips use /usr/libexec/ld.elf_so, not the archaic
gnu-ld-derived code in /usr/src/gnu/usr.bin/ld.  And,

jiho@postal.c-zone.net quotes Castor Fu as saying:
On 05-Jun-98 Castor Fu wrote:

> You know, I asked something similar to this several months ago
> for the mips architecture.  Turned out that people were not
> using the gnu ld.so at all, and that the dynamic linker in common
> use was not in the source tree at all.  This resulted in the
> appropriate code getting dropped into /usr/src/libexec/ld.elf_so.

Uh, Castor did ask about the source, but the sequence of events isn't
quite right.

The old mips ld.so was derived from copylefted source which was on the
FTP server but not in the NetBSD source tree, since it was a
``temporary solution''.  Chris Demetriou suggested porting ld.elf_so
to mips should be straighforward. It turned out the mips ABI and ELF
caused a number of weird, unexpected bugs which took several heads
(and months) to fix.

Last year, I'd rewritten the libc startup code (which had an embeded
constant derived from the compiler-generated stackframe offsets, which
_changed_, ugh!), the ld.elf_so startup code, and added the necessary
kernel support.  The next stumbling block was a bug in GNU ld's
section alignment, which broke the first call from within ld.elf_so's
entrypoint.

Michael Hitch found and fixed that, and added the necessary reloc
types. the result was something that almost worked.  I helped Michael
figure out what was going wrong with the multiply-defined-symbol bug
(in both the old ld.so and ld.elf_so).  Then we had to clean up some
Alpha-specific reloc and fixup support which someone had carelessly
put into MI code.

Anyway -- the short story is that ld.elf_so wasn't MI when we started
the mips port, it is reasonably MI now, we have more idea about kinds
of things that can go wrong, and further ELF ports shouldn't involve
nearly so much heartache.