This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: more prelink
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Sun, 29 Sep 2002 23:30:01 +0200
- Subject: Re: more prelink
- References: <200209280339.XAA90598@bromo.msbb.uc.edu>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Sep 27, 2002 at 11:39:06PM -0400, Jack Howarth wrote:
> Jakub,
> I think I have stumbled over another issue with prelink that
> could be problematic unless addressed. Currently the glibc srpms
> are using a postinst script to prelink libc.so.6 with the
> --reloc-only flag so it is relinked to the specified base address.
> If I do that on entropy with...
>
> /usr/sbin/prelink --reloc-only=0x40000 /lib/libc-2.2.94.so
I'm terribly sorry to say, but now that I think about it, --reloc-only
for libc.so makes no sense on ppc/x86-64/sparc* etc. Sorry for
forgotting about this.
It speeds things up on REL or ELF_MACHINE_REL_RELATIVE arches only.
ELF_MACHINE_REL_RELATIVE are those where R_*_RELATIVE relocs have the
addend in *r_offset. ppc/x86-64/sparc* usually have zero there.
Even if I changed back binutils to put addend to both r_addend and *r_offset
on ppc, ELF_MACHINE_REL_RELATIVE could not be defined because there are
already many -z combreloc binaries and libraries out there I think
and they'd suddenly fail in weird ways.
R_*_RELATIVE relocs can be skipped on the other
arches (ppc, x86-64, sparc*, ...) if the library is prelinked, not
just prelink -r'ed. Then it guarantees *r_offset has the proper value.
Jakub