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? 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? Walter > Now, the trouble is, when you update a library, you must update all > the binaries. This means (as far as I see it) either you also update > all the appropriate binaries by running prelink again on all the > binaries, or you update the packages the binaries are in. > > The second option would cause libraries to have huge number of > dependancies, and would make minor upgrades of libraries horrendous > for dial up users. > > The first option has slightly more subtle problems. The problem is > that it means when you update a library, it goes and unpredictably > modifies binaries. This plays absolute havoc with things like > tripwire, and any kind of security.
