Comment imprimer le chemin de recherche ld (linker)

Quelle est la manière d'imprimer les chemins de recherche qui ont été regardés par ld dans l'ordre dans lequel il recherche.

Vous pouvez le faire en exécutant la commande suivante:

ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012

gcc transmet quelques chemins -L supplémentaires à l'éditeur de liens, que vous pouvez lister avec la commande suivante:

gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,;  ,g' | tr \; \\012

Les réponses suggérant d'utiliser ld.so.conf et ldconfig ne sont pas correctes car elles font référence aux chemins recherchés par l'éditeur de liens dynamique d'exécution (c'est-à-dire à chaque fois qu'un programme est exécuté), ce qui n'est pas le même que le chemin recherché par ld (c'est-à-dire à chaque fois un programme est lié).

Sous Linux, vous pouvez utiliser ldconfig, qui gère la configuration et le cache ld.so, pour imprimer les répertoires recherchés ld.soavec

ldconfig -v 2>/dev/null | grep -v ^$'\t'

ldconfig -vimprime la recherche de répertoires par l'éditeur de liens (sans onglet de début) et les bibliothèques partagées trouvées dans ces répertoires (avec un onglet de début); le greprécupère les répertoires. Sur ma machine, cette ligne s'imprime

/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)

Les premiers chemins, sans hwcapdans la ligne, sont soit intégrés, soit lus depuis /etc/ld.so.conf. L'éditeur de liens peut ensuite rechercher des répertoires supplémentaires sous le chemin de recherche de la bibliothèque de base, avec des noms tels que sse2correspondant à des capacités de processeur supplémentaires. Ces chemins, avec hwcapdans la ligne, peuvent contenir des bibliothèques supplémentaires adaptées à ces capacités CPU.

Une dernière remarque: utiliser -pau lieu de -vci - dessus recherche le ld.socache à la place.

Je ne suis pas sûr qu'il existe une option pour simplement imprimer le chemin de recherche efficace complet.

Mais: le chemin de recherche se compose de répertoires spécifiés par des -Loptions sur la ligne de commande, suivis des répertoires ajoutés au chemin de recherche par des SEARCH_DIR("...")directives dans le (s) script (s) de l'éditeur de liens. Vous pouvez donc le résoudre si vous pouvez voir les deux, ce que vous pouvez faire comme suit:

Si vous appelez lddirectement:

• Les -Loptions sont ce que vous avez dit qu'elles sont.
• Pour voir le script de l'éditeur de liens, ajoutez l' --verboseoption. Recherchez les SEARCH_DIR("...")directives, généralement vers le haut de la sortie. (Notez que ce ne sont pas nécessairement les mêmes pour chaque appel de ld- l'éditeur de liens a un certain nombre de scripts de l'éditeur de liens par défaut intégrés différents, et choisit entre eux en fonction de diverses autres options de l'éditeur de liens.)

Si vous créez un lien via gcc:

• Vous pouvez transmettre l' -voption à gccafin qu'elle vous montre comment elle appelle l'éditeur de liens. En fait, il n'appelle normalement pas lddirectement, mais indirectement via un outil appelé collect2(qui vit dans l'un de ses répertoires internes), qui à son tour invoque ld. Cela vous montrera quelles -Loptions sont utilisées.
• Vous pouvez ajouter -Wl,--verbosedes gccoptions pour le faire passer --verboseà l'éditeur de liens, pour voir le script de l'éditeur de liens comme décrit ci-dessus.

La commande la plus compatible que j'ai trouvée pour gcc et clang sous Linux (grâce à armando.sano):

$ gcc -m64 -Xlinker --verbose  2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g'  | grep -vE '^$'

si vous donnez -m32, il affichera les bons répertoires de bibliothèque.

Exemples sur ma machine:

pour 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

pour 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 question est étiquetée Linux, mais peut-être que cela fonctionne aussi bien sous Linux?

gcc -Xlinker -v

Sous Mac OS X, cela imprime:

@(#)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' -Xlinkeroption gccci-dessus passe simplement -và ld. Toutefois:

ld -v

n'imprime pas le chemin de recherche.

Version Mac: $ ld -v 2, je ne sais pas comment obtenir des chemins détaillés. production

Library search paths:
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/