¿Cuál es la forma de imprimir las rutas de búsqueda que buscó ld en el orden en que busca?
¿Cuál es la forma de imprimir las rutas de búsqueda que buscó ld en el orden en que busca?
Respuestas:
Puede hacer esto ejecutando el siguiente comando:
ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
gcc pasa algunas rutas -L adicionales al enlazador, que puede enumerar con el siguiente comando:
gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012
Las respuestas que sugieren usar ld.so.conf y ldconfig no son correctas porque se refieren a las rutas buscadas por el enlazador dinámico de tiempo de ejecución (es decir, cada vez que se ejecuta un programa), que no es lo mismo que la ruta buscada por ld (es decir, cuando un programa está vinculado).
ld
la ruta de búsqueda de s. Por ejemplo, a veces tengo que compilar un código fuente makefile
o generar un archivo MAKE a partir de un configure
script o de uno CMakeLists.txt
aún más complicado como vala
o srt
. Es difícil para mí modificar la ld
ruta de búsqueda en tales casos
En Linux, puede usar ldconfig
, que mantiene la configuración y caché de ld.so, para imprimir los directorios de búsqueda ld.so
con
ldconfig -v 2>/dev/null | grep -v ^$'\t'
ldconfig -v
imprime la búsqueda de directorios por el enlazador (sin una pestaña principal) y las bibliotecas compartidas que se encuentran en esos directorios (con una pestaña principal); el grep
obtiene los directorios. En mi máquina, esta línea se 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)
Las primeras rutas, sin hwcap
en la línea, están integradas o se leen desde /etc/ld.so.conf. El enlazador puede buscar directorios adicionales en la ruta de búsqueda básica de la biblioteca, con nombres como los sse2
correspondientes a capacidades adicionales de la CPU. Estas rutas, con hwcap
en la línea, pueden contener bibliotecas adicionales adaptadas para estas capacidades de CPU.
Una nota final: usar en -p
lugar de lo -v
anterior busca en el ld.so
caché.
export LD_LIBRARY_PATH=/some/other/dir
, no afectará la salida de este comando? Parece que no funciona al 100%?
LD_LIBRARY_PATH
al permitir la depuración. Por ejemplo LD_DEBUG=libs /lib/ld-linux.so --list cat
(puede usar cualquier ejecutable, elegí cat
lo primero que se me ocurrió). Podría valer la pena " search path
". Tenga en cuenta que si tiene una /etc/ld.so.cache
que coincide con todas las bibliotecas necesarias, no podrá ver la ruta de búsqueda del sistema incorporado, porque no llegará tan lejos.
gcc
ruta de búsqueda es la misma con estos?
No estoy seguro de que haya alguna opción para simplemente imprimir la ruta de búsqueda efectiva completa.
Pero: la ruta de búsqueda consiste en directorios especificados por -L
opciones en la línea de comando, seguidos por directorios agregados a la ruta de búsqueda por SEARCH_DIR("...")
directivas en los scripts del enlazador. Entonces puede resolverlo si puede ver ambos, lo que puede hacer de la siguiente manera:
Si estás invocando ld
directamente:
-L
opciones son lo que haya dicho que son.--verbose
opción. Busque las SEARCH_DIR("...")
directivas, generalmente cerca de la parte superior de la salida. (Tenga en cuenta que estos no son necesariamente los mismos para cada invocación de ld
: el vinculador tiene varios scripts de vinculador predeterminados integrados diferentes y elige entre ellos en función de otras opciones de vinculador).Si está vinculando a través de gcc
:
-v
opción a gcc
para que le muestre cómo invoca el vinculador. De hecho, normalmente no invoca ld
directamente, sino indirectamente a través de una herramienta llamada collect2
(que vive en uno de sus directorios internos), que a su vez invoca ld
. Eso le mostrará qué -L
opciones se están utilizando.-Wl,--verbose
a las gcc
opciones para que pase --verbose
al enlazador, para ver el script del enlazador como se describió anteriormente.-T script
mi script reemplazó por completo el script predeterminado de ld y solo miré donde señalé.
El comando más compatible que he encontrado para gcc y clang en Linux (gracias a armando.sano):
$ gcc -m64 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$'
si da -m32
, generará los directorios correctos de la biblioteca.
Ejemplos en mi máquina:
para 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
para 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 pregunta está etiquetada Linux, pero ¿tal vez esto funciona tan bien en Linux?
gcc -Xlinker -v
En Mac OS X, esto 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/
[...]
La -Xlinker
opción de gcc
arriba solo pasa -v
a ld
. Sin embargo:
ld -v
no imprime la ruta de búsqueda.
-Lpath
. Entonces la respuesta de @ Raphaël Londeix es mejor.
Versión para Mac: $ ld -v 2, no sé cómo obtener rutas detalladas. salida
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld -v 2
ld
. La gente de Binutil lo deshabilitó en los scripts de compilación. Ha sido deshabilitado por años.
/usr/local/..
que se produce un error de biblioteca faltante y la vinculación falla. Tengo que cambiar el nombre/usr/local
cada vez para excluir esa ruta de búsqueda. ¿Hay una manera simple de excluir o anular la/usr/local
ruta?