2011-11-17 11 views
13

Quando eseguo ldd contro una libreria condivisa, come libphp5.so vedo che ha una dipendenza da libmysqlclient.so.16:Come sono determinati i percorsi di dipendenza delle librerie condivise su Linux?

 
$ ldd ./libphp5.so 
libmysqlclient.so.16 => /usr/lib/mysql/libmysqlclient.so.16 
[other dependencies snipped out] 

sono questi i nomi dei file di dipendenza e percorsi (/usr/lib/mysql/libmysqlclient.so.16) cotto in binario libreria condivisa? O è questo percorso determinato da altri mezzi come ad esempio tramite /etc/ld.so.conf.d/mysql-i386.conf, che contiene tra l'altro:

/usr/lib/mysql/ 

Un altra cosa che mi è sconcertante:

C'è una libreria condivisa che ho che compilo dai sorgenti. Questo ha una dipendenza da libmysqlclient_r. I gcc opzioni del compilatore per la produzione di questo sguardo questa libreria come:

 
gcc -shared -L/usr/lib/mysql -lmysqlclient_r [+various other switches] 

Quando faccio ldd mylib.so vedo:

 
libmysqlclient_r.so.16 => /usr/lib/mysql/libmysqlclient_r.so.16 (0x0055c000) 

Tuttavia nella directory /usr/lib/mysql vedo:

 
-rwxr-xr-x. libmysqlclient_r.so -> libmysqlclient_r.so.16.0.0 
lrwxrwxrwx. libmysqlclient_r.so.16 -> libmysqlclient_r.so.16.0.0 
-rwxr-xr-x. libmysqlclient_r.so.16.0.0 
lrwxrwxrwx. libmysqlclient.so -> libmysqlclient.so.16.0.0 
lrwxrwxrwx. libmysqlclient.so.16 -> libmysqlclient.so.16.0.0 
-rwxr-xr-x. libmysqlclient.so.16.0.0 

libmysqlclient_r.so è un collegamento simbolico a libmysqlclient_r.so.16.0.0, quindi perché ldd mostra la dipendenza come libmysqlclient_r.so.16. C'è della magia che mi manca qui?

Essendo stato uno sviluppatore di Windows per molti anni, sono un po 'nuovo per lo gcc e lo sviluppo su Linux.

La mia distribuzione Linux è CentOS 6.0 x86-32bit.

risposta

14

Si può vedere quali percorsi sono provenienti da dove eseguendo

LD_DEBUG=libs ldd ./libphp5.so 

sono questi i nomi dei file di dipendenza e sentieri (/usr/lib/mysql/libmysqlclient.so.16) cotto nel binario libreria condivisa ?

Il nome file è quasi certamente. Il percorso di solito non lo è. Si può vedere ciò che viene cotto nel binario con

readelf -d ./libphp5.so 

Cercare (NEEDED) e (RPATH) voci.

Dare anche a man ld.so una lettura.Ci sono molti fattori che influenzano le ricerche caricatore come dinamici per le librerie condivise: ld.so.conf, LD_LIBRARY_PATH, se l'eseguibile è suid o no, come glibc è stato configurato, che -rpath impostazioni sono stati dati in fase di collegamento, ecc ecc

+0

Grazie, questo è alcuni suggerimenti utili. – Kev

+0

Non ne hai idea, ma vorrei poterlo manomettere ancora di più. La mia domanda derivava dall'impossibilità di caricare 'libmysqlclient_r' usato in un pacchetto di pacchetti di formaggio Python (MySQL-Python) nonostante compili/costruisse bene. 'LD_DEBUG = libs ldd' è stata la mia vita più sicura. Si scopre che il file di percorso salvato in '/ etc/ld.co.conf.d' non finisce in' .conf' e il mio file '/ etc/ld.so.conf' specifica:' include ld.so. conf.d/*. conf'. Quindi la cartella '/ usr/lib/mysql' non è mai stata cercata. – Kev

1

sono questi i nomi dei file di dipendenza e sentieri (/usr/lib/mysql/libmysqlclient.so.16) cotto nel binario libreria condivisa?

Sì, possono essere e spesso lo sono. La parola chiave qui è -rpath. Tuttavia, ld.conf ha anche la sua opinione. L'intero sistema è piuttosto complesso, sfortunatamente.

Problemi correlati