sslug-teknik team mailing list archive

[Donald Axel <donax@xxxxxxxxxx>]

Min workstation kører en opdateret Scientific Linux 4.1 (SL-43, endnu ikke 44).

Jeg prøvede at bygge og installere Xen-3.0.3_0-src.tar.bz2 og det gik
uden problemer. Mærkeligt nok er der opstået det problem at gvim ikke
kunne starte uden at opføre sig tumpet, hvilket jeg fandt ud at på
lyden af harddisken og ved derefter at liste open files, "lsof" for
gvim - processen.

Gvim processen stod gudhjælpemig og
kørte /usr/local/src/Xen/xen-3.0.3_0-src rekursivt igennem for at
scanne filer, vistnok kun .o og .so filer, men alligevel.

OK, jeg fjernede (flyttede) source dir, og det løste dette problem; men
nu er der somme tider at gvim ikke vil generere vindue, samme gælder for
andre programmer, som har lyd/billed funktioner: gxine og Seamonkey(Mozilla).

Det er lidt underligt, synes jeg. Der er ikke pillet
ved /etc/ld.so.conf eller satellit filerne i /etc/ld.so.conf.d/

Der må være et Xen library som griber ind i load processen. Og
dependencies må være totalt gakkede siden Gvim begynder at kigge efter
alle mulige ting. OBS: ldd siger vist ikke noget om, hvilke libraries
en proces (dannet ud fra et program) leder efter, hvis funktionaliteter
er lavet ved at programmets shared-object (.so) fil indeholder load af
andre shared objects evt. ud fra konfigurerbar liste, så man kan have
flere eller færre funktionaliteter til rådighed? 


SPØRGSMÅL:

Er der nogen, der kan bekræfte / afkræfte at det er Xen, som har
påvirket det dynamiske load af shared objects?
==============================================


Nu fjerner jeg alt, hvad Xen har installeret og hvis det ikke hjælper,
så installerer jeg den nyeste Scientific Linux (eller en Debian) på en
anden partition. Jeg skal nok melde tilbage, om det hjælper. 





-- 
http://d-axel.dk/blox http://d-axel.dk/pub/breach/linuxbog/