This is the mail archive of the
mailing list for the glibc project.
Re: Prelinking of shared libraries
- To: bastian at kde dot org
- Subject: Re: Prelinking of shared libraries
- From: Chiaki Ishikawa <Chiaki dot Ishikawa at personal-media dot co dot jp>
- Date: Fri, 11 May 2001 20:57:55 +0900 (JST)
- cc: libc-alpha at sources dot redhat dot com
>Yes, that seems the easiest way to do it. Some people pointed out a scheme
>where you have a central "link/relocation service" (either in user or kernel
>space) which maps the linked library into the address-space of the process.
>Geoff Keating told me that AIX uses such an approach. That basically moves
>the linking/relocation from installation time to "first used" time. I am not
>exactly sure what the benefits of one of these schemes above the other has in
>complex to me.
Long time ago, a minicomputer OS had such a service even for
figuring out to what an numerical address in an object file (or
an executable file) would resolve: "what" being a symbol and possibly
>From the end user's point of view,
this service simpilified certain tasks such as symbol priting
at the time of crash or writing one's own stack tracer, etc..
The service, I think, was offered since the 32 bit VM OS and
the old 16 bit OS were just merged and
there were two different types of the object files being
Having the service in the kernel simplified the task of
end users (mostly programmers) during the time when
the each successive revision of OS might introduce newer
object file types and relocation types and such, I think.
Of course, this is the pure end users's point of view.
>From the implementor's point of view, this just moves
where the service is provided: in the kerenel via system call,
by system supplied libraries such as ELF handling libraries, etc..
The benefits to the end users would be the less dependence
on the object format changes and the required access
method changes as long as the user program
doesn't need the new features in the new object file format.
Ishikawa, Chiaki email@example.com.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051