Is prelinking on linux for shared libraries any good (proven)

Question

The shared libraries have a problem of latency of linking when the executable is loaded. There is a concept of 'prelink' on linux and preloading on MAC, which actually helps removing this link time. Has this prelink on linux been proven efficient ? Also when was it introduced, and is it being used widely ?

Answer 1

I'm not sure of the benefits of prelink, but I have bumped into a downside. Coredumps generated on one host cannot be loaded by gdb on another. prelink confuses it.

My environment separates production hosts and development hosts, so in general, no debugging allowed in production.

Answer 2

When you compile a library it gets mapped into a specific part of memory address space - sort of a default place to find it. The address is somewhere in 32-bit space for most systems, or 64-bit space for newer systems. If two libraries point to the same space, they can still be loaded, but only one can use the space at a time. This creates extra work for Linux, in that it has to swap the space back-and-forth between the two libraries.

Prelink on Linux works by creating a unique address space mapping for each .so in the paths you give it. Now, the two libraries will point to different address spaces, so both can be loaded at the same time without having to swap between them or move them around at runtime.

It's been around since at least 2004 according to Wikipedia, and Jakub's prelink page shows revisions back through 2001. Some modern Linux systems (at least Ubuntu) have deprecated prelinking, their internal linking systems are efficient in remapping libraries on-the-fly or they provide some other mechanism to allow libraries to load without conflicts.