Under Linux, most applications are in a special Executable and Linkable Format (ELF) that allows them to be smaller. Instead of including all needed libraries, the program file has references to them, which are resolved (or linked) when the code is loaded for execution.

Here; you might recognise a classic time versus space compromise: a smaller file size, but a higher loading time. If your program requires only a few libraries, the linking process is quick, but for larger programs that use several libraries, the linking process gets noticeably longer.

If you are game to using a bit more disk space (and spending some time preparing all files), you can use the prelink command to do the linking phase in advance
and store the needed libraries within the program file itself, so it will be ready to execute as soon as it is loaded. (Actually, I fudged a bit here. When the program is loaded, the libraries are checked to verify they haven't changed since the prelinking, but that check is much speedier than doing the linking itself.) Using prelink in this way obviously requires more disk space (for there will be a copy of every pre linked library within each executable file), but with the current large disks, this won't even be noticed.

In order to pre link your programs, you need to set up a configuration file (/etc/prelink. earif'), so prelink knows where to search for shared libraries and what programs to work with should you opt for the -a option and prelink everything possible. The format of this file is simple: blank lines don't matter, comments start with a # c.haracter, and the rest of the lines should be something like the following:
-h anotherDirectoryButAllowingForSymlinks
-b fileToSkip
The -I lines specify directo~ies that should be processed.
The -h lines are pretty much the same, but allow for symlinks, which will be followed, so the prelink process might end up working with files actually residing in other directories than the ones you originally specified. Finally, the -b lines show blacklisted programs (patterns also
can be used) that should be skipped by the prelinking process. I recommend leaving these lines alone. If your prelink experiments show that certain programs cannot
be prelinked (you'll get an error message if you try),
you should add an appropriate -b line to avoid future unnecessary warnings. As an example, Listing 1 shows some portions of my (already provided in openSUSE) letc/prelink. conf file.
Listing 1: Portions of the provided openSUSE letc/pre1ink.conf file
# Acrobat Reader
-b lusr IXll R6/libl AcrobatS/Reader I intellinux/binl acroread
-b lusr/XllR6/lib/Acrobat7/Reader/intellinux/bin/acroread
# RealPlayer
-b lusr Ilib/Realplayer8/realplay
# Files to skip -b * .la
-b *.png
-b * .py
-b * .pl
-b * .pm
-b . sh
f kernel modules -b /l ib/modules
-1 llib
-1 Ilib64
-1 lusr/lib
-1 lusr/lib64
-1 lusr IXllR6/lib
-1 lusr/XllR6/lib64
-1 lusr/ketberos/lib
-1 lusr/kerberos/lib64
-1 lopt/kde3/lib
-1 lopt/kde3/lib64
If you want to prelink a single program, just implement prelink the Program Path And Name, and if the program can be relinked successfully (remember my comment-this just isn't feasible for some programs), the original binary ELF file will be overwritten with the new, larger, all-including version.

You could start a massive prelinking session by executing prelink -a, which will go through all the -1 and -h directories in /etc/prelink.conf and prelink everything it finds. Here are a few more options to note:
•Do a dry run by including the -n option. This generates a report of all results, but no changes will be committed to disk. Use this to see whether there are unexpected problems or files to be excluded.

•Include the -m option so prelink will try to conserve memory, if you have many libraries in your system (very likely) and not a very large memory. On my own machine, if I omit this option, prelink fails to work, so my usual command to prelink everything possible is pre link -m -a.

•If you dislike the prelinked files, or if you get tired of pre linking everything every time you get updated libraries, use the -u parameter to undo the changes. Executing prelink -u aPrelinkedProgramName will restore the program to its previous, unlinked format, with no fuss. Of course, for a radical throwback to the original situation, do pre link -a -u.

The prelinked versions of all programs are executed just like the normal ones, but will load a bit faster, thus providing a snappier feel. I have found conflicting opinions as to actual, measured results, but most references point to real speedups.