Ainsi parlait Guillaume Cottenceau : [.. Thanks for all those useful headers ..]
> 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 almostwould 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... The headers were easier to understand :-) Could you explain *a bit* for us poor ignorants ? Does it only concerns KDE obj-prelink support, or is it a more wide concern ? -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
