On Sun, 12 Nov 2006 11:27:34 +0100 Donald Axel <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Nov 2006 22:34:52 -0500 > Benji Fisher <[EMAIL PROTECTED]> wrote: > > > > What can cause a program to search through the whole tree of the > > > source of an installed software package? > > > > There are lots of things that could cause this. For example, a > > line like > > > > :vimgrep /todo/g /path/to/xen-3.0.3_0-src/**/*.c > > > > in your vimrc file or any automatically-loaded plugin would do it. I > > suggest trying > > > > $ gvim -u NONE > > Thank you for your helpful answer! > > right now gvim -u NONE doesn't come up at all, so it _is_ in the load > system that something has gone wrong. > > My vimrc files are minimalistic! > > There are other applications which take much longer to load, and > sometimes do not get to opening a window at all, like gxine. I suspect > it to be related to some library module, but I have no idea which except > it seems that applications using "alsa" are affected. But then again: > Why would "Gvim" use "alsa"? > > I am scratching the installation (which is shameful;-) but all the same > there is an update for SL-43 to SL-44 :-) Ok - the new installation does not show the same slow load and multi-library search. I am not sure how to debug this, I kept the old inst. for reference because I think it is important to know what can cause unnecessary high disk/CPU-load. I am going to compare ld.so.conf, /lib, /usr/lib and dig into the additions on the old system (when I get the time;-), but actually I tend to think that that one can find useful guidance via Google and mailing lists. So far we can conclude that Gvim depends on some more or less nice libraries and their modules. My prime suspect is still "alsa", why do things try to load "alsa"? The answer must be that it is caused by some monolithic GUI-lib.
