Qual è il modo per stampare i percorsi di ricerca che nel guardato dal ld nell'ordine esso cerca.
Qual è il modo per stampare i percorsi di ricerca che nel guardato dal ld nell'ordine esso cerca.
Risposte:
Puoi farlo eseguendo il seguente comando:
ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
gcc passa alcuni percorsi -L extra al linker, che puoi elencare con il seguente comando:
gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012
Le risposte che suggeriscono di usare ld.so.conf e ldconfig non sono corrette perché si riferiscono ai percorsi cercati dal linker dinamico di runtime (cioè ogni volta che viene eseguito un programma), che non è lo stesso del percorso cercato da ld (cioè ogni volta un programma è collegato).
ld
il percorso di ricerca. Ad esempio, a volte devo compilare un codice sorgente makefile
o generare makefile dallo configure
script o da CMakeLists.txt
o anche più complicati come vala
o srt
. In ld
questi casi è difficile modificare il percorso di ricerca
Su Linux, è possibile utilizzare ldconfig
, che mantiene la configurazione e la cache di ld.so, per stampare la ricerca delle directory ld.so
con
ldconfig -v 2>/dev/null | grep -v ^$'\t'
ldconfig -v
stampa la ricerca delle directory dal linker (senza una scheda iniziale) e le librerie condivise che si trovano in quelle directory (con una scheda iniziale); la grep
ottiene le directory. Sulla mia macchina, questa riga viene stampata
/usr/lib64/atlas:
/usr/lib/llvm:
/usr/lib64/llvm:
/usr/lib64/mysql:
/usr/lib64/nvidia:
/usr/lib64/tracker-0.12:
/usr/lib/wine:
/usr/lib64/wine:
/usr/lib64/xulrunner-2:
/lib:
/lib64:
/usr/lib:
/usr/lib64:
/usr/lib64/nvidia/tls: (hwcap: 0x8000000000000000)
/lib/i686: (hwcap: 0x0008000000000000)
/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib/sse2: (hwcap: 0x0000000004000000)
/usr/lib64/tls: (hwcap: 0x8000000000000000)
/usr/lib64/sse2: (hwcap: 0x0000000004000000)
I primi percorsi, senza hwcap
nella riga, sono integrati o letti da /etc/ld.so.conf. Il linker può quindi cercare directory aggiuntive nel percorso di ricerca della libreria di base, con nomi come sse2
corrispondenti a capacità CPU aggiuntive. Questi percorsi, con hwcap
in linea, possono contenere librerie aggiuntive su misura per queste funzionalità della CPU.
Un'ultima nota: usare -p
invece di -v
sopra cerca ld.so
invece la cache.
export LD_LIBRARY_PATH=/some/other/dir
, non influenzerà l'output di questo comando ?! Sembra che non funzioni al 100%?
LD_LIBRARY_PATH
abilitando il debug. Ad esempio LD_DEBUG=libs /lib/ld-linux.so --list cat
(puoi usare qualsiasi eseguibile, ho scelto cat
la prima cosa che mi è venuta in mente). Potrebbe valere la pena cercare " search path
". Nota che se ne hai uno /etc/ld.so.cache
che soddisfa tutte le librerie necessarie, non riuscirai a vedere il percorso di ricerca del sistema integrato, perché non andrà così lontano.
gcc
percorso di ricerca è lo stesso con questi?
Non sono sicuro che ci sia alcuna opzione per stampare semplicemente il percorso di ricerca completo efficace.
Ma: il percorso di ricerca è costituito da directory specificate dalle -L
opzioni sulla riga di comando, seguite da directory aggiunte al percorso di ricerca da SEARCH_DIR("...")
direttive negli script del linker. Quindi puoi risolverlo se riesci a vedere entrambi, cosa che puoi fare come segue:
Se stai invocando ld
direttamente:
-L
opzioni sono qualunque cosa tu abbia detto che sono.--verbose
opzione. Cerca le SEARCH_DIR("...")
direttive, in genere vicino alla parte superiore dell'output. (Si noti che questi non sono necessariamente gli stessi per ogni invocazione di ld
: il linker ha un numero di script di linker predefiniti integrati diversi e sceglie tra loro in base a varie altre opzioni di linker.)Se stai collegando tramite gcc
:
-v
opzione a in gcc
modo che ti mostri come invoca il linker. Infatti, normalmente non invoca ld
direttamente, ma indirettamente tramite uno strumento chiamato collect2
(che vive in una delle sue directory interne), che a sua volta invoca ld
. Questo ti mostrerà quali -L
opzioni vengono utilizzate.-Wl,--verbose
alle gcc
opzioni per farlo passare --verbose
al linker, per vedere lo script del linker come descritto sopra.-T script
mio script ha sostituito completamente lo script predefinito di LD e ho guardato solo dove ho indicato.
Il comando più compatibile che ho trovato per gcc e clang su Linux (grazie ad armando.sano):
$ gcc -m64 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$'
se lo dai -m32
, produrrà le directory della libreria corrette.
Esempi sulla mia macchina:
per g++ -m64
:
/usr/x86_64-linux-gnu/lib64
/usr/i686-linux-gnu/lib64
/usr/local/lib/x86_64-linux-gnu
/usr/local/lib64
/lib/x86_64-linux-gnu
/lib64
/usr/lib/x86_64-linux-gnu
/usr/lib64
/usr/local/lib
/lib
/usr/lib
per g++ -m32
:
/usr/i686-linux-gnu/lib32
/usr/local/lib32
/lib32
/usr/lib32
/usr/local/lib/i386-linux-gnu
/usr/local/lib
/lib/i386-linux-gnu
/lib
/usr/lib/i386-linux-gnu
/usr/lib
La domanda è taggata Linux, ma forse funziona anche con Linux?
gcc -Xlinker -v
In Mac OS X, questo stampa:
@(#)PROGRAM:ld PROJECT:ld64-224.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em
Library search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib
Framework search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/
[...]
L' -Xlinker
opzione di cui gcc
sopra passa solo -v
a ld
. Però:
ld -v
non stampa il percorso di ricerca.
-Lpath
. Quindi la risposta di @ Raphaël Londeix è migliore.
Versione per Mac: $ ld -v 2, non so come ottenere percorsi dettagliati. produzione
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld -v 2
ld
. La gente di Binutil l'ha disabilitato negli script di compilazione. È stato disabilitato per anni.
/usr/local/..
cui si verifica un errore di libreria mancante e il collegamento non riesce. Devo rinominare/usr/local
ogni volta per escludere quel percorso di ricerca. Esiste un modo semplice per escludere o sovrascrivere il/usr/local
percorso?