Re: more prelink

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Sep 27, 2002 at 09:06:28AM -0400, Jack Howarth wrote:
> Jakub,
>     A couple more questions. I noticed that the rawhide specfile
> for glibc 2.2.92-2 had this as a part of its postinst scripts...

Dunno whether all the prelink stuff shouldn't go to a separate prelink
mailing list...

> # For now disable prelinking of ld.so, as it breaks statically linked
> # binaries built against non-NDEBUG old glibcs (assert unknown dynamic tag)
> # /usr/sbin/prelink -c ./prelink.conf -C ./prelink.cache \
> #  --mmap-region-start=0x40000000 $RPM_BUILD_ROOT/%{_lib}/ld-*.so
> /usr/sbin/prelink --reloc-only=0x42000000 $RPM_BUILD_ROOT/%{_lib}/i686/libc-*.so
> Is it still the case that ld.so should not be prelinked or has that

It will always be the case, as long as there will be some broken
statically linked binaries someone cares about.
The fix went in 2002-03-30, so any statically linked binary using nss
linked with older glibc, unless that glibc has been explicitely linked
with -DNDEBUG (I don't know about other distros, but we added that in ~7.0
I think) would stop working.
When one prelinks manually, it is a form of saying I don't have such
binaries (and if he finds he has them, he can prelink -u).

> be fixed in glibc cvs yet? Also I am wondering if you could explain how
> the values for --reloc-only= were decided for each arch...as on ppc
> we don't have a value for that yet. Thanks in advance for any information.

You just pick some nice number in the virtual address range for libraries
(see bottom of each arch-*.c in prelink). On 32-bitters it shouldn't be too
far from where kernel starts mapping libraries (otherwise database folks who
want gobs of memory will cry, since there will be libc.so in the middle),
but shouldn't be too near either (for most apps libc.so is
mmaped after mmaping 5-50 other libraries and the aim is that at least for
the wast majority of apps libc.so will be able to mmap at the address
given in --reloc-only). On PPC this is complicated
by the strange library layout (first below binary, afterward upwards).
The best is to take some totally unprelinked system and check out where
libraries are mmaped in an average program. Note that you definitely want
libc.so to be close enough to others for the 24bit relocs.

	Jakub