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).
ldil percorso di ricerca. Ad esempio, a volte devo compilare un codice sorgente makefileo generare makefile dallo configurescript o da CMakeLists.txto anche più complicati come valao srt. In ldquesti 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.socon
ldconfig -v 2>/dev/null | grep -v ^$'\t'
ldconfig -vstampa 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 grepottiene 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 hwcapnella 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 sse2corrispondenti a capacità CPU aggiuntive. Questi percorsi, con hwcapin linea, possono contenere librerie aggiuntive su misura per queste funzionalità della CPU.
Un'ultima nota: usare -pinvece di -vsopra cerca ld.soinvece la cache.
export LD_LIBRARY_PATH=/some/other/dir, non influenzerà l'output di questo comando ?! Sembra che non funzioni al 100%?
LD_LIBRARY_PATHabilitando il debug. Ad esempio LD_DEBUG=libs /lib/ld-linux.so --list cat(puoi usare qualsiasi eseguibile, ho scelto catla prima cosa che mi è venuta in mente). Potrebbe valere la pena cercare " search path". Nota che se ne hai uno /etc/ld.so.cacheche soddisfa tutte le librerie necessarie, non riuscirai a vedere il percorso di ricerca del sistema integrato, perché non andrà così lontano.
gccpercorso 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 -Lopzioni 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 lddirettamente:
-Lopzioni sono qualunque cosa tu abbia detto che sono.--verboseopzione. 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:
-vopzione a in gccmodo che ti mostri come invoca il linker. Infatti, normalmente non invoca lddirettamente, 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 -Lopzioni vengono utilizzate.-Wl,--verbosealle gccopzioni per farlo passare --verboseal linker, per vedere lo script del linker come descritto sopra.-T scriptmio 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' -Xlinkeropzione di cui gccsopra passa solo -va 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/localogni volta per escludere quel percorso di ricerca. Esiste un modo semplice per escludere o sovrascrivere il/usr/localpercorso?