On Sun, 27 Apr 2003 12:04:38 +0200, Walter Hofmann wrote: >On Sun, 27 Apr 2003, Nick Boyce quoted: > >> Anyway, prelinking is when you now modify the binary, and tell it >> about the particular version of the libraries that it links (say >> version 1.0.3 or whatever) Now when you run the binary and use that >> particular version of the library, it loads the library into a >> specific memory address, and the binary already knows the memory >> address of all the functions and data structures. >> This speeds up loading time and saves memory. >> If the library version changes, then it falls back on the old method. > >Given this and until a better method is in place the maintainers could >just pre-link their (non-OpenGL) packages against whatever version of >the libraries they happen to have on their system. >When their users are lucky they have the same libraries and get a >speed-up, if not they just get the same performance they have today. > >Would this work?
Well IANADD, but it sounds ok to me, especially for formal releases of KDE where everything would be designed to be used together : the worst case would seem to be that every time a support library is re-released (e.g. security fix) then the DSA would need to include advice about re-running prelink on dependent packages to retain optimum performance, and then re-baselining Tripwire (or similar) if required. >If an executable is pre-linked against a number of libraries and one of >them changes, breaks this the pre-linking of one or of all libraries? >If a library only chnages slightly, ie. no change in code size, will the >old pre-linked binaries still work (in a pre-linked fashion) with the >new library? Sorry - no idea :-) Nick Boyce Bristol, UK -- I came, I saw, I concurred
