This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: more prelink

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, 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 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 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 in the middle),
but shouldn't be too near either (for most apps is
mmaped after mmaping 5-50 other libraries and the aim is that at least for
the wast majority of apps 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 to be close enough to others for the 24bit relocs.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]