Sì la prima cosa che ho fatto è stata proprio la rinomina della dir ".mozilla" in "mozilla.bk".
La situazione adesso però è stranamente cambiata!
(questo mi porta a pensare sempre più spesso che l'informatica non possa essere annoverata tra le scienze esatte).
Dunque adesso la rimozione del modulo:
Ha finalmente avuto l'effetto atteso, infatti non vi è più /usr/bin/seamonkey e compagnia.
Però se ricarico il modulo a quanto pare la magagna persiste e gli errori che ho riportato sono sempre quelli.
Per scrupolo, ho provato a lanciare un "ldd /usr/bin/seamonkey-bin" anche se francamente non so precisamente come è organizata la faccenda in slax (cioè il fatto che il software venga montato in loop piuttosto che eessere installato alla maniera classica non vorrei che portasse a conclusioni errate...va bè). Ecco cosa è risultato:
Codice: Seleziona tutto
# ldd /usr/bin/seamonkey-bin|grep not
libmozjs.so => not found
libxpcom.so => not found
libxpcom_core.so => not found
libplds4.so => not found
libplc4.so => not found
libnspr4.so => not found
libsmime3.so => not found
libssl3.so => not found
libnss3.so => not found
libnssutil3.so => not found
libsoftokn3.so => not found
libldap60.so => not found
libprldap60.so => not found
libldif60.so => not found
libsqlite3.so => not found
Ci credo che non si avvia...
La libreria mancante: libplds4.so è presente in realtà, ma si trova in /usr/bin piuttosto che in /usr/lib.
Ora, un modulo slax non è altro che una directory compressa in un pacchetto lzm, e attivandolo vine montato in loop praticamente andando a piazzare i files delle varie sottodir nei vari percorsi del sistema.
Chi ha creato il modulo in questione ha messo le librerie in /usr/bin, piuttosto che in /usr/lib.
Forse ha anche una certa logica per due motivi:
1) prima di tutto non è così scorretto perchè prima dell'altro giorno il modulo è sempre stato funzionante senza problemi. Quindi questo non può essere il solo motivo del mancato funzionamento attuale.
2) Ipotrebbe avere anceh una certa logica per evitare di sovrascrivere eventuali librerie che già lavorano sul sistema ed ovviamente si trovano dove ci si aspetta ovvero in /usr/lib e compagnia.
Tanto per fare una prova adesso faccio un link simboico in /usr/lib a /usr/bin/libmozjs.so e vediamo cosa succede.
In effetti ora cambia l'errore
Codice: Seleziona tutto
# seamonkey-bin
seamonkey-bin: error while loading shared libraries: libxpcom.so: cannot open shared object file: No such file or directory
Il problema quindi apparentemente è il seguente:
seamonkey cerca le librerie nelle dir predisposte penso da una qualche variabile d'ambiente, e probabilmente questa variabile non comprende /usr/bin...
Il fatto però è che prima funzionava, e come diavolo faceva?
A questo proposito provo ad aggiungere "/usr/bin" in:
Codice: Seleziona tutto
# cat /etc/ld.so.conf
/usr/local/lib
/usr/i486-slackware-linux/lib
/usr/bin
Codice: Seleziona tutto
# ldconfig
ldconfig: /usr/bin/libplc4.so is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/bin/libnssutil3.so is not an ELF file - it has the wrong magic bytes at the start.
Codice: Seleziona tutto
ldconfig: File /usr/lib/libopenobex.so.1.3.0 is empty, not checked.
Compaiono strani errori che coinvolgono proprio libplc4 tra gli altri.
Ma il fatto èche il modulo di seamonkey è stato scaricato e ricaricato e anche se vi fosse stato un "trauma" al sistema che avesse danneggiato la libreria in questione, non avrebbe comunque coinvolto il pacchetto che se ne stava tranquillo fuori dal sistema... cioè ricaricaandolo la libreria dovrebbe essere come nuova...
Forse il discorso sta tutto qui, forse ho capito:
potrebbe anche essere che scaricando il modulo magari non vengano cancellati proprio tutti i files e che per esempio libplc4 resti nel sistema, non sapreri dire perquale santo ma proviamo ad ipotizzarlo per un attimo. Vado a verificare:
scompatto il pacchetto seamonkey-2.0.3.lzm in una dir $TESTDIR e vado a confrontare "diff" il file $TESTDIR/usr/bin/libplc4.so con l'eventuale rimasuglio presente sul sistema in /usr/bin. Ci sono due possibilità, il file presente sul sistema è ancora lì perchè fa parte di qualche altro modulo ancora caricato in memoria (improbabile vista la collocazione di una libreria in /usr/bin) oppure sta ancora lì perchè è corrotto edi in qualche modo non è possibile eliminarlo del tutto con la disattivazione del modulo, discorsi e ipotesi campati in aria forse, maproviamo a crderci e verifichiamo:
Codice: Seleziona tutto
# losetup -a|grep sea
# ls /usr/bin/libplc4.so
/usr/bin/libplc4.so
# diff /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so /usr/bin/libplc4.so
Binary files /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so and /usr/bin/libplc4.so differ
# activate /mnt/sda2/saved-modules/seamonkey-2.0.3.lzm
bash-3.1# losetup -a|grep sea
/dev/loop24: [0802]:133 (/mnt/sda2/saved-modules/seam diff /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so /usr/bin/libplc4.so
Binary files /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so and /usr/bin/libplc4.so differonkey-2.0.3.lzm)
CVD?
A pensar male si fà peccato ma ci s'azzecca a quanto pare...
In effetti quella libreria non viene cancellata alla disattivazione del modulo di seamonkey, inoltre alla riattivazione del modulo questa non viene sovrascritta infatti è differente da quella sana presente nella directory dove ho scompattato il pacchetto, In pratica in qualche modo fallisce il montaggio in loop.
Ora provo a forzare un attimo la mano disattivando nuovamente il modulo ed eliminando a mano la libreria incriminata:
Ho provato ma quando poi riattivo il modulo stessa storia, stessi errori.... strano... però non mi ha dato alcun errore quando ho cancellato il file con "rm".
Boh, se vi viene in mente qualcosa dite pure