>: > Remove /sbin/ldconfig - not used on mips ports anymore
>: 
>: What's the reson for not using ldconfig ? If the speedup gained by
>: caching library locations is insignificant, we should drop it entirely
>: maybe.

The real reason for not including ldconfig is that it's no longer
used.  ldconfig _was_ used on mips, back when we shipped a GNU-derived
ld.so and ldconfig.  Once that we added support for all the necessary
MIPS-specific relocs to ld.elf_so amd moved the Alpha-spcecific cruft
from the MI code into alpha-specific source files, we could use
ld.elf_so on mips.  So ldconfig is strictly unnecessary.

Simon noticed ldconfig was still in the pmx sets files while building
a mips snapshot, so I asked him to garbage-collect it.


>ld.elf_so has zero knowledge of library caching.  ELF uses rpath as its main
>way of finding libraries (and ELF doesn't use directory lookups - it has the
>name of the library to find directly available thanks to -soname).
>
>There has been inconclusive discussion about adding a ldconfig-alike
>fallback to ELF ports, mainly on the alpha list.

Some developers -- notably cgd -- have expressed very strong opinions
against `ldconfig'.  I dont pretend to speak for Chris, but I dont see
any signficant architectural difference between the symlink farms in
each directory, as we use now, and keeping the same info about ELF
shlib versions in a *local, per directory only* `cache file'. 

As long as the Right Things get done at library-build and library-
install time, they're moral equivalents, and architecturally identical
down to the symlink-versus-special-file tradeoffs..


I thought the big architectural issue over ELF was whether or not to
provide a `ld.so.conf' or moral equivalent.  To allow a sysadmin to
provide sytsem-wide defaults which override compiled-in rpath
directives without clobbering everybody and anybody's
LD_LIBRARY_PATH-- say, for people who need to install packages into
/usr/local but who still want to use the precompiled binary pkgs.