Most common applications make use of shared libraries. These shared libraries need to be loaded into memory at runtime and the various symbol references need to be resolved. For most small programs this dynamic linking is very quick. But for programs written in C++ and that have many library dependencies, the dynamic linking can take a fair amount of time.
On most systems, libraries are not changed very often and when a program is run, the operations taken to link the program are the same every time. Prelink takes advantage of this by carrying out the linking and storing it in the executable, in effect prelinking it. In order for the linker, you need ld-linux.so in glibc; to recognize the prelinking you need >=glibc-2.3.1-r2.
Prelinking can cut the startup times of applications. For example, a typical KDE program's loading time can be cut by as much as 50%. The only maintenance required is re-running prelink every time a library is upgraded for a pre-linked executable.
First update your portage tree, as many of the needed applications are new and bug-fixes are constantly added.
# emerge sync
Next make sure you have portage-2.0.46 or better installed. This is needed so that portage can recognize the prelinked binaries and thus uninstall them correctly when requested. This is because prelinking changes the MD5sum of a binary.
# emerge ">=portage-2.0.46"
Now you can emerge the prelinking tool. The emerge process automatically verifies that your system can prelink safely.
# emerge prelink
A number of people get errors in emerging prelink because of the failed tests. The tests were put in for safety reasons, prelink's behavior is undefined if you disable them. The emerge errors are usually only dependent on the core packages; binutils, gcc, and glibc. Try re-emerging those packages in that order.
If you have a set of steps that reproduces the emerge error on another system
please e-mail them to
Portage automatically generates the file
Unfortunately you cannot prelink files that were compiled by old versions
of binutils. Most of these applications come from pre-compiled, binary
only packages which are installed in
PRELINK_PATH_MASK="/opt"
I use the following command to prelink all the binaries in the directories
given by
# prelink -afmR
The options explained: |
---|
-a |
-f |
-m |
-R |
The cause of this problem is from badly compiled shared libraries that were compiled without the -fPIC gcc option for all their object files.
The following is a list of the problem libraries and which packages to re-emerge if you have the above error.
For the ORBit library /usr/lib/libIIOP.so.0.5.17 # emerge ">=sys-apps/tcp-wrappers-7.6-r4" ORBitFor zlib library usr/lib/libz.so.1.1.4 # emerge ">=sys-libs/zlib-1.1.4"For svgalib, /usr/lib/libsvga.so.xx # emerge ">=media-libs/svgalib-1.9.16"For the XFree openGL library, libGLU.so.1 # emerge ">=x11-base/xfree-4.2.1-r2"For libpcap.so.0.6 # emerge ">=net-libs/libpcap-0.7.1-r2"For the lcms library, /usr/lib/liblcms.so.1 # emerge ">=media-libs/lcms-1.09"
If you are having trouble with prelinking QT/KDE, then first try upgrading to >=x11-base/xfree-4.2.1-r2 and >=x11-libs/qt-3.1.0-r1. If QT still fails then try compiling QT without xinerama support by adding myconf="-no-xinerama ${myconf}" in the qt ebuild.
Here are the libraries that haven't been fixed or cannot be fixed:
If your problem library was not listed please report it with, preferably, a patch to add -fPIC to the relevant CFLAGS.
You need to use the -f option for
This has been fixed in sys-libs/glibc-2.3.1-r2 on 2002/11/18, re-emerge glibc if yours is older.
Also doing
The accelerated openGL libraries that come in the nvidia-glx package have
been compiled in a non-standard way and so
Where glibc is concerned, there is no such thing as a 100% static binary. If you statically compile a binary with glibc, it may still depend on other system files. Below is an explanation by Dick Howell,
"I suppose the idea is that everything will be in the downloaded file, so nothing depends on the local libraries on the target system. Unfortunately with Linux, and I think anything else using GLIBC, this still isn't quite true. There's this "libnss" (name service switch, some people seem to call it network security system) which provides functions for accessing various databases for authentication, network information, and other things. It's supposed to make application programs independent of the separately configured actual network environment of the machine. A nice idea, but changes to GLIBC can lead to problems loading it. And you can't statically link "libnss", since it is configured for each machine individually. The problem comes, I think, mainly from statically linking other GLIBC libraries, notably "libpthread", "libm", and "libc", from which come incompatible calls to "libnss" functions."
This a known problem, kindly diagnosed
In order to prelink on a system with grsecurity using a
randomized mmap() base, it is necessary to turn "randomized mmap()
base" OFF for
Prelinking can drastically speed up the start up times for a number of
large applications. Support is built into Portage. Prelinking is also safe
as you can always undo the prelinking for any binary if you come across any
problems. Just remember that when you update glibc or other libraries that
you prelinked with, you need to rerun