I hate prelink too. I ran into the problem for a different reason while playing with checkpointing (http://ppadala.blogspot.com/2005/07/checkpointing-and-prelinking.html)
You can disable it in /etc/sysconfig/prelink.
 

Thanks Pradeep, but I'm afraid my mentor in Fedora does not like the idea of disabling prelink to run preload ;).
 

I lived under impression that prelink is some evil hack. And it's no longer needed when programs are linked with "-Wl,-O1" in LDFLAGS. Do you really still need prelink?
 

I can't imagine how -Wl,-O1 may have anything to do with prelinking. Lemme explain what prelink does: It reads all shared libraries installed on your system and assigns nonoverlapping address spaces to each of them and relocates them to that place, and saves them back to the disk. Then for every binary on the system too, prelinks it to some empty slot in the address space.

This way, at run time, most probably no relocation is needed, since all objects involved are already relocated to some location, and no clash happens. That's what prelink does. This cannot be done by the linker when compiling the application, since it involves altering the shared objects too.

Whether the prelinking is an effective way of optimizing the startup time, that's another question, and most probably not for anything other and OO.o and maybe Firefox.
 

Prelink gets you three things, which can be obtained via other routes:

1) As behdad has already stated, you get a faster startup time in code with many runtime relocations. This has most impact on large C++ applications, since they tend to have more relocations than C applications. There are hacks to minimise the number of relocations in other ways on some architecture (using relative addressing).

2) With the -R option, you get static address space randomisation. Obviously, something similar can also be done by the kernel.

3) The non-obvious benefit is the increase in shared memory. Because the relocations are present in the on-disk binary, they remain shared by the COW infrastructure; if they're done by the dynamic loader in memory, each binary gets its own copy of any pages that include a relocation. This adds up when you've got many different binaries running (as against many forked copies of one binary). The mergemem project looked at providing an equivalent behaviour in the kernel (by merging pages that came from one binary, were changed, but now match).
 

Thanks Simon for the detailed comment. The part about COW pages was new to me, never thought about it before.
 

I was mistaken by some email from old (pre-warty) days on Ubuntu mailing list. Thanks for clarification!