This is not a specifically Gvim related question though I
experienced this first with gvim.
After compiling and installing xen-3.0.3_0-src on a SL-43 system I
tried to read some file with gvim and it took 5 minutes or slightly
more to open the file and display its content.
SL-43: Scientific Linux version 4.3.
As this of course was very intriguing (read-arm clicking for a long
time) I tried to follow what files were opened with
"lsof -p XXXX"
It showed that the gvim-process walked through the entire
"xen-3.0.3_0-src" tree opening and closing files, .so files and .o files.
After I moved this tree time for loading gvim was reduced to some 5
seconds first time and 0 seconds on next load.
Same applies to gxine (and probably other multimedia applications).
A vim process in xterm did not scan the xen-source dir for .o
and .so files.
--- QUESTION ---
What can cause a program to search through the whole tree of the
source of an installed software package?
--- ADDITIONAL INFO ---
Xen did not add to /etc/ld.so.conf.d or ld.so.conf or change any
other conf-file in /etc. I will also ask on the Xen lists whether this
odd behaviour is known (and return if something interesting shows up).
Thank you in advance for any reaction to this question. I am sure
I can verify, upgrade or reinstall to permanently cure the system. But
I want to understand what happened.
And finally: Many thanks for the super-editor gvim and this
interesting mail-list.
/Donald Axel
--
http://d-axel.dk/ -- Donald Axel, Consultant -- [EMAIL PROTECTED]
