This is the mail archive of the
mailing list for the glibc project.
Re: Prelinking of shared libraries
- To: Andreas Jaeger <aj at suse dot de>
- Subject: Re: Prelinking of shared libraries
- From: Waldo Bastian <bastian at kde dot org>
- Date: Fri, 4 May 2001 14:50:14 -0700
- Cc: bastian at kde dot org, libc-alpha at sources dot redhat dot com
- References: <email@example.com>
On Friday 04 May 2001 00:29, Andreas Jaeger wrote:
> Is there a way to avoid the symbol lookup or to prelink to some
There are two issues of concern: time and memory. In order to get better
page sharing you basically must get rid of all relocations. To do that you
need to take into account all of your dependencies as well. That's not
impossible I think.
The idea would be to do the prelinking as if you were linking an actual
application and then store the result for later reuse. When you are about to
link an actual application you would first try to see if you can use the
result of prelinking. If that isn't possible (e.g. one of the depending
libraries changed) you would need to do regular linking and any other library
that depends on this library wouldn't be able to use a prelinked library
This approach is basically outlined in the Nelson paper.
Although it talks about Spring it also states:
"However the basic caching techniques we have described do not require a
user-level server. A UNIX system might implement an equivalent dynamic
library cache as an operating system service that is used by the exec
The prelinking could then be done just like ldconfig currently updates the
ld.so.cache and the prelink results could be stored either seperately in the
file system, or maybe as an additional ELF section in the library. Since
linking mostly concerns the .data and .got sections maybe one could add an
additional .data.prelinked and .got.prelinked then.
firstname.lastname@example.org | SuSE Labs KDE Developer | email@example.com