prelinking

Every time a dynamically linked program starts, the dynamic linker does work: it picks addresses for each shared library, then walks the relocations and fills in the GOT for every symbol the program uses. For a program that loads many large libraries, this startup work is repeated on every single launch even though, on a stable system, the libraries usually end up at the same places and resolve to the same addresses. Prelinking is the optimization that does this work ONCE, ahead of time, and caches the result so startup can skip most of it.

The idea, in plain steps: a prelink pass run in advance assigns each shared library a fixed, non-conflicting load address across the whole system, then pre-computes and writes the resolved relocation values directly into the binaries and libraries. When a prelinked program later starts, the dynamic linker checks whether the assumptions still hold (the libraries are where prelink expected and have not changed); if so, it can use the cached addresses and skip most of the relocation work, making startup faster. Apple's older equivalent was called prebinding, which served the same purpose on Mac OS X. Both are essentially a bet that the set and placement of libraries is stable enough to precompute the linking.

It matters as a historical lesson more than a current default. Prelinking gave a measurable startup win in an era of slower machines and limited library sets, but it has largely fallen out of favor and is disabled or removed on most modern systems. The reasons are honest: it fundamentally conflicts with address-space layout randomization (fixing library addresses is exactly what ASLR wants to avoid), it has to be redone whenever a library is updated (so package managers must re-run it), and modern dynamic linkers plus faster hardware shrank the benefit. So treat prelinking as a clever idea whose security cost outweighed its speed benefit — useful to understand, rarely used today.