>> And this is different from the current a.out implementation _how_?

> ...this is our chance to FIX it.

What, you think users are going to care that we've switched binary
formats?  This brings them what features?  Really, we could rip it out
at any time and it would have exactly the same impact as if we don't
implement it for ELF.

(Also, "see everything I've said before.")

As an aside, Matt wrote:
> The search order for our ld.elf_so is:

> 	1) rpaths in the object(s)
> 	2) default path (defined to be /usr/lib:/usr/local/lib in the source)
> 	3) LD_LIBRARY_PATH

This seemed wrong to me, so I spent a while examining the ld.elf_so
code.  If I read the flow right, it calls _rtld_add_paths() first on
the rpaths in the objects, then on RTLD_DEFAULT_LIBRARY_PATH, then on
LD_LIBRARY_PATH.  The trick is that _rtld_add_paths() adds path in
*front* of the current search path unless they start with a leading
':'.  (The default library path does not start with a ':'.)  So the
actual search order seems to be:

	1) LD_LIBRARY_PATH
	2) default path
	3) rpaths in the object(s)

which still seems wrong to me (2 and 3 should be switched).  Perhaps
someone with a modern system can test empirically?  What's worse is
that if you're adding a directory to the search path and it already
exists, _rtld_add_paths() doesn't pull that directory to the front or
end of the search path; it does nothing.  So if 2 and 3 were switched
and I wanted to use LD_LIBRARY_PATH to override an rpath component
with a system library directory, I would lose.