Problema dipendenze

[h725]

Salve,

ho una Slackware 12.1 appena installata. Ho installato swaret e ho impostato i repository di Slacky.
Ho installato il pacchetto "keepassx" e cio' ho comportato l'installazione di ulteriori pacchetti:

googleearth-4.3.7204.836-i486-2sl.tgz
pyqt4-4.4.2-i486-1as.tgz
qt4-4.4.0-i686-2as.tgz
wengophone-2.1.1-i686-2as.tgz

Ora ho problemi con diversi software:

$ firefox
/usr/lib/firefox-2.0.0.14/firefox-bin: symbol lookup error: /usr/lib/libgobject-2.0.so.0: undefined symbol: g_regex_unref

$ keepassx
keepassx: /opt/google-earth/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by keepassx)

$ thunderbird
/usr/lib/thunderbird-2.0.0.12/thunderbird-bin: symbol lookup error: /usr/lib/libgobject-2.0.so.0: undefined symbol: g_regex_unref

Mi potreste dare gentilmente qualche indicazione per risolvere?
Grazie

[conraid]

Se non ti serve rimuovi wengophone. Se ti serve correggi il file /etc/ld.so.conf e poi dai il comando ldconfig
E' il solito problema di ordine di path delle librerie, cerca nel forum e trovi tante persone che hanno avuto lo stesso inconveniente
Però keepassx richiede solo qt4 di esterno a Slackware, quindi mi sembra strano ed il mio consiglio è... togli Swaret

p.s.
da quel che vedo sembra che anche google-earth modifica ld.so.conf, questo è strano. Ha sempre funzionato senza fare casini.

comunque è un problema di ordine di path delle librerie, e di swaret che fa casino (se non hai detto esplicitamente tu di installare quei pacchetti)

[slucky]

più che swaret, che a quanto a mi risulta ha dato parecchi problemi agli utenti, ti consiglio slapt-get e il suo frontend grafico gslapt, che è ottimo e risolve in auto anche le dipendenze, su slacky.eu trovi i pacchetti e il link agli indirizzi dei repo

Saluti

[h725]

Ho risolto modificando il file /etc/ld.so.conf e dando ldconfig.
Ho messo /usr/lib un rigo sopra a /usr/share/wengophone

Credevo che /lib e /usr/lib venissero PRIMA di ogni altro path presente in /etc/ld.so.conf.. non e' cosi'?

Grazie infinite

[Dani]

L'ordine di ricerca delle librerie è:

- DT_RPATH
- $LD_LIBRARY_PATH
- DT_RUNPATH
- /etc/ld.so.cache
- /etc/ld.so.conf, /lib, /usr/lib

I due DT_* sono entry della sezione dinamica degli eseguibili elf, a volte contengono un offset ad una stringa nella string table del programma che indica al linker dove cercare le librerie.
/lib e /usr/lib sono incluse di default, personalmente li toglierei da ld.so.conf assieme ai path messi da swaret.
Per le dipendenze ti consiglio slackyd, è ancora beta ma per trovare i tgz ci mette molto molto meno di swaret e non prende iniziative che spettano all'utente !

[h725]

Ciao!
Grazie per la risposta
Innanzitutto provero' subito slackyd, ho visto parecchi thread sul programma e sono curioso (e anche un po' stufo di swaret

Un'ultima domanda sulle dipendenze: perche' nell'ordine di ricerca c'e' sia ld.so.cache che ld.so.conf ?
ld.so.conf non e' solamente il file di configurazione che genera effettivamente ld.so.cache?

tu mi hai detto che toglieresti da ld.so.conf /usr/lib e /lib, e anche i path aggiunti da swaret (nel mio caso, ad esempio, quello di wengophone): ma poi come farebbe wengophone a trovare le sue librerie??

in effetti parte comunque.... ma mi chiedo perche'!

grazie ancora

[conraid]

tu mi hai detto che toglieresti da ld.so.conf /usr/lib e /lib, e anche i path aggiunti da swaret (nel mio caso, ad esempio, quello di wengophone): ma poi come farebbe wengophone a trovare le sue librerie??

in effetti parte comunque.... ma mi chiedo perche'!

Esatto, quei software hanno bisogno delle proprie librerie, che si sovrappongono a quelle contenute in /usr/lib, se quindi lo togli (come dovrebbe essere normale) alcuni programmi prendono le libri di wengophone credendole quelle di sistema
Quindi va aggiunto anche quel path e prima di wenghophone o altri software "rompicazzo"

Se usi questi sofware non puoi togliere purtroppo quei path a meno che non togli anche il path delle librerie di quei software. Prova.
Io li tengo per comptabilità con possibili programmi (che attualmente non uso).
Che poi in effetti il mio ld.so.conf sia così vecchio che ha sempre path di librerie X che non esistono più, beh... la pigrizia fa brutti scherzi

[Dani]

Ciao!
Un'ultima domanda sulle dipendenze: perche' nell'ordine di ricerca c'e' sia ld.so.cache che ld.so.conf ?
ld.so.conf non e' solamente il file di configurazione che genera effettivamente ld.so.cache?

In effetti in man ld-linux non vedo ld.so.conf, mi sa che ho cannato io

tu mi hai detto che toglieresti da ld.so.conf /usr/lib e /lib, e anche i path aggiunti da swaret (nel mio caso, ad esempio, quello di wengophone): ma poi come farebbe wengophone a trovare le sue librerie??

in effetti parte comunque.... ma mi chiedo perche'!

Spesso i programmi che hanno delle librerie condivise ma "private" nel pacchetto stesso hanno al loro interno una stringa che indica la directory che le contiene. In questi casi per quel programma la ricerca dovrebbe avvenire prima di tutto in quella directory.
Puoi verificare questo usando il programma readelf, parte delle binutils, usando lo switch -d. L'entry in questione è DT_RPATH.
Nel caso in cui un programma non avesse queste entry, se non si riesce a venirne fuori, consiglierei di creare un'alias o una funzione nel bashrc che modifichi al volo la variabile LD_LIBRARY_PATH prima di avviare il programma:

Codice: Seleziona tutto

alias programma="LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/directory/esotica programma"

Così facendo non ci saranno problemi con gli altri programmi e si manterrà ld.so.conf pulito.
Comunque alla fine i pacchetti che si portano dietro problemi simili si contano su una mano, googleearth, openoffice, wengophone e poco altro