a better comparison

a better comparison

Prelinking doesn't store paths anywhere. Storing the paths of shared libraries in the binary would be a complete waste of time, because the paths are *already* cached in /etc/ld.so.cache.

What prelinking does is tries to find a set of initial load addresses for all the shared libraries on the system such that those addresses are available in every binary that needs those libraries; then it modifies the libraries accordingly. Libraries prepared in this way don't require relocation (or at least not much; C++ code in particular still has two relocations per virtual method table entry) and so startup times are reduced because ld-linux.so.2 doesn't have to do all that relocation at startup time, and memory consumption is reduced because fewer text pages are marked writable.

Downsides:
- obviously binaries you build after running prelink might require relocations, and shared libraries you build after running prelink almost certainly will. But they would have done had you never run prelink at all, so this is not much of a loss.
- prelink modifies system libraries. So their md5sums will change, tripwire and samhain will trip unexpectedly, and if you're doing it while the system is running your memory consumption will go *up* afterwards because all those libraries have changed inode numbers so text page sharing between the pre- and post-relocation copies of the library can't take place.
- dlopen()ed shared libraries can't benefit, because there's no way prelink can tell that they're used (working it out for sure would require solving the halting problem).
- binaries and shared libraries must be linked correctly; e.g. if they use symbols from a library foo, they *must* say -lfoo at link time or prelink will get confused. (Before now, if a library they relied upon themselves pulled in the library they needed, they could just use that; but that is fragile.)