Le Samedi 20 Octobre 2001 17:09, Guillaume Cottenceau scribit : > > > 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 > > [... thanks for the whole unneeded quoting ...] > > > > 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 ? > > Personally I don't understand enough to explain. Maybe Gwenole would be?
>From what I understand. I will take an example. Suppose you prelink prog a with lib b and c. if you change c for d, prelinking doesn't work anymore. You have to prelink one more time. > > > 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) That's why he propose to do prelink as a cron job ( for example each night it prelink everything in case you updates/changes some packages during the day ). In this case it may check before if rpm databse change, if yes it launch prelinking job. If not, nothing happen. It suggest also a weekly frequence as the user can install prog via tar.gz ( no trace in rpm database ). > > > 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.> > Does it only concerns KDE obj-prelink support, or is it a more wide So for him release prelinked binaries is not good for 2 reasons : 1�/ portability : glibc must support prelinking but the problem is that glibc doesn't support prelinking for all the architecture > > > it would mean the bins or libs (on most architectures) cannot be run if glibc >has not prelinking support 2�/ from the above example if you change some packages, prelinking doesn't work anymore and you will have to recompil your package in order to prelink them with your new libs. It's painfull. Imagine for us ( cooker ). > > > 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 So prelinking should be run the user ( cf cron job or un prog you run that prelinked your binaries ) and packager should not releases prelinked binaries. > > > that's why prelink is a process everyone can run on their own After he takes the case of 7.2 ( Red Hat 7.2 ). It says that in 7.2 binaries are linked with combreloc ( -z option ) and also that there is cache. > > > 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 thanks to this, startup is increase by 50% ( prelinking perform better however ) So if we want to use prelinking we must have some new option i.e : --undo to stop using prelinking ( revert to default behaviour ) in an easy way. i.e don't have to install some unprelinked paackages and erase all the prelinked ones. > > >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) --verify to verify the consistence of yoyr librairies ( does the package you install is prelinked with the version you personnnally have in your system. If not warn you because the prelinking is not going to work ). If you install a package with a prelinking to lib version a and you have the version b, you will have to down/upgrade in oreder to have version a. > > > the latter one means rpm -V or tripwire can verify nobody tempered with them but >prelink Of course prelinking must be test in order to find possible bugs, problems, and solutions ... No major distribution use prelinking or ship relminked binaries. It's the same for devfs : Mandrake is the first major distribution which use devfs and as we can see it needs many more testing and correction ( unfortunately the test period was too short ). Off-Topic : where can I find a tutorial concerning devfs ? ( customize devfsd.conf, /lib/dev-state, force detection, etc ... ). > > > b) it needs lot of testers who beat on it Before people think about ship prelinked binaries, maybe they should optimise their code before. > > > Plus there are some C++ optimizations I want to add... -- http://perso.wanadoo.fr/linux_wizard/index.html - Le g�nie consiste � voir ce que tout le monde a vu et � penser ce que personne n'a pens�. Albert Einstein�???
