-------------------- Start of forwarded message --------------------
X-From-Line: gc Sat Oct 20 10:40:28 2001
Return-Path: <[EMAIL PROTECTED]>
Received: from 216.71.116.161 [216.71.116.161]
by localhost with POP3 (fetchmail-5.9.4)
for gc@localhost (single-drop); Sat, 20 Oct 2001 10:40:28 +0200 (CEST)
Received: from listman.redhat.com (listman.redhat.com [199.183.24.211])
by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with ESMTP id DAA27359;
Sat, 20 Oct 2001 03:40:10 -0500
Received: from listman.redhat.com (localhost.localdomain [127.0.0.1])
by listman.redhat.com (Postfix) with ESMTP
id 129B92F20B; Sat, 20 Oct 2001 04:40:07 -0400 (EDT)
Delivered-To: [EMAIL PROTECTED]
Received: from lacrosse.corp.redhat.com (host154.207-175-42.redhat.com
[207.175.42.154])
by listman.redhat.com (Postfix) with ESMTP id 2E4E02F0FF
for <[EMAIL PROTECTED]>; Sat, 20 Oct 2001 04:39:47 -0400 (EDT)
Received: (from mail@localhost)
by lacrosse.corp.redhat.com (8.11.6/8.9.3) id f9K8dlb31960
for [EMAIL PROTECTED]; Sat, 20 Oct 2001 04:39:47 -0400
Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [207.175.42.156])
by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id f9K8dkf31954
for <[EMAIL PROTECTED]>; Sat, 20 Oct 2001 04:39:46 -0400
Received: (from jakub@localhost)
by devserv.devel.redhat.com (8.11.0/8.11.0) id f9K8dmO31364
for [EMAIL PROTECTED]; Sat, 20 Oct 2001 04:39:48 -0400
From: Jakub Jelinek <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Jakub's hot-rodded KDE binaries?
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<20011020082425.KNG4964.mtiwmhc26.worldnet.att.net@there>
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20011020082425.KNG4964.mtiwmhc26.worldnet.att.net@there>; from
[EMAIL PROTECTED] on Sat, Oct 20, 2001 at 01:24:24AM -0700
X-loop: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.1
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
X-Reply-To: Jakub Jelinek <[EMAIL PROTECTED]>
List-Help: <mailto:[EMAIL PROTECTED]?subject=help>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://listman.redhat.com/mailman/listinfo/roswell-list>,
<mailto:[EMAIL PROTECTED]?subject=subscribe>
List-Id: A public discussion group concerning the Roswell beta release of Red Hat
Linux <roswell-list.redhat.com>
List-Unsubscribe: <https://listman.redhat.com/mailman/listinfo/roswell-list>,
<mailto:[EMAIL PROTECTED]?subject=unsubscribe>
List-Archive: <https://listman.redhat.com/pipermail/roswell-list/>
Date: Sat, 20 Oct 2001 04:39:48 -0400
X-UIDL: 2l^!!$]["!mXX"!S-Q"!
Lines: 43
Xref: obiwan.mandrakesoft.com 2001-10.roswell-list:919
On Sat, Oct 20, 2001 at 01:24:24AM -0700, J Hayward wrote:
> So what your saying is that 7.2 IS NOT prelinked already? What kind of bugs,
> if any, might prelinking 7.2 create?
Shipping prelinked binaries or libraries makes no sense. prelink is a
process which should be run any time one updates some libraries or binaries
(this doesn't have to be done immediately, since the binaries will still
work, but prelinking cannot be used), so ideally it is run e.g. from cron
e.g. nightly if rpm database has changed (ie. new packages have been
installed that day), or say weekly to catch user built programs.
Packaging prelinked bins or libs in rpms would be bad because
a) it would mean the bins or libs (on most architectures) cannot be run
if glibc has not prelinking support (either programs would only work
with LD_BIND_NOW=1 because .plt would need to be reinitialized, or
ld.so is missing ElfW(Rela) relocation (i386, arm))
b) as prelinking depends on what exact packages you have installed, it
couldn't be often used anyway when you install different packages than
the exact expected set (that's why prelink is a process everyone can
run on their own)
What 7.2 has out of box even without running prelink is that important
libraries/binaries have been linked with -z combreloc (well, it is the
default in our binutils) and ld.so has a one-entry lookup cache, which
should cut KDE startup times spent in ld.so down to about 50% (but
prelinking cuts far more).
The major issue with prelink is so that I wouldn't consider it experimental:
a) --undo and --verify needs to be fully supported (the former one means you
can get back at unprelinked binaries or libraries any time you wish
(without the need to restore from backup or reinstall), the latter one
means rpm -V or tripwire can verify nobody tempered with them but prelink
b) it needs lot of testers who beat on it
Plus there are some C++ optimizations I want to add...
Jakub
_______________________________________________
Roswell-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/roswell-list
-------------------- End of forwarded message --------------------
--
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
