Re: question regarding prelinking (was: (inc. note from dpkg developers) (was:Bug#XXXXXX: (far too many packages) needs rebuilt for prelinking))
On Friday 17 Jan 2003 12:17 pm, Emile van Bergen wrote:
> If linking plays such a big part in the (noticeable) startup time of
> these applications, then IMHO that signifies broken design, and indeed,
> inventing a new .so for every three functions /is/ broken design.
I wouldnt say so, the design is very modular and clean. Just look at the
number of developers on the konqueror project compared to mozilla, and in my
opinion (many will disagree) it is a much better browser. It also means that
you dont have redundent libraries loaded.
> More of all that linking should be done at build time, not at run time.
> In most cases you need exactly matching minor versions for all those
> KDE/Gnome support libraries anyway - just look at how often the soname
> versions are incremented.
>
> Just provide a single Qt lib, a single KDE lib that uses it, and the
> same for GTK+ and Gnome, resp.
But then things are not modular, and you load libraries you dont need. If your
running say kword, you dont want the ssh kio library loaded, or the smtp
library or the pop3 library etc..
> Make no illusions, nobody's going to use your utility functions
> standalone anyway, outside of those environments.
But they do, for instance psi optionally can use the kde libraries for some
functions, although it is a qt application and doesnt require kdelibs
(prelinking wont help here as it loads the libraries itself).
> This way, you can have two libs per environment, plus glibc and possibly
> libstdc++. I cannot imagine that the linker need so much time to map
> those. If it does, then the APIs are simply too wide (which they are).
But kde and probably gnome provide far too much funtionality to be in just
lib. For instance many use GDM instead of KDM but still use KDE as their
dekstop environment, what would be the point in loading the libgtk-html
library for this? Even glibc is split into multiple libraries (libm, libgcc -
not strictly part of glibc i know but you see the point). Prelinking is also
a hack to get round some of the limitations of gcc/glibc and the dynamic
loader, so you cant blame the applicaiton fully. I agree that prelinking is
not the optimal solution, but until limitations of the loader are fixed (i
dont even know if the can be without breaking binary compatibilty of existing
libraries/binaries) it does make a significant difference. Personally, im
very looking forward to a gcc-3.2 compiled kde getting into sid so i can
prelink everything.
Just my thoughts on the matter
Tom
Reply to: