按照搜索顺序打印ld查找的搜索路径的方法是什么。
按照搜索顺序打印ld查找的搜索路径的方法是什么。
Answers:
您可以通过执行以下命令来执行此操作:
ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
gcc将一些额外的-L路径传递给链接器,您可以使用以下命令列出该路径:
gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012
建议使用ld.so.conf和ldconfig的答案是不正确的,因为它们引用了运行时动态链接程序搜索的路径(即,每当执行程序时),而该路径与ld搜索的路径(即,无论何时程序已链接)。
ld
s搜索路径的全局方法。例如有时我必须编译从源代码makefile
从或产生生成文件configure
脚本或从CMakeLists.txt
或甚至更复杂的问题,例如vala
或srt
。ld
在这种情况下,我很难修改搜索路径
在Linux上,您可以使用ldconfig
维护ld.so的配置和缓存,以打印出通过ld.so
进行搜索的目录
ldconfig -v 2>/dev/null | grep -v ^$'\t'
ldconfig -v
打印出链接程序搜索的目录(不带前导标签)和在这些目录中找到的共享库(带前导标签);将grep
得到的目录。在我的机器上,此行打印出来
/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)
第一行路径hwcap
是内置的,或从/etc/ld.so.conf中读取。然后,链接器可以在基本库搜索路径下搜索其他目录,其名称类似于sse2
对应的其他CPU功能。这些路径(hwcap
随行附送)可以包含为这些CPU功能量身定制的其他库。
最后一点:使用-p
而不是-v
上面搜索ld.so
缓存。
export LD_LIBRARY_PATH=/some/other/dir
,怎么可能不影响该命令的输出?似乎无法100%工作?
LD_LIBRARY_PATH
通过启用调试来包括其中的路径。例如LD_DEBUG=libs /lib/ld-linux.so --list cat
(您可以使用任何可执行文件,我cat
首先想到的就是它)。可能值得为“ search path
” 窥探。请注意,如果您有一个/etc/ld.so.cache
与所有需要的库都匹配的,则不会看到内置的系统搜索路径,因为它不会那么远。
gcc
搜索路径与这些相同?
我不确定是否有任何选项可以简单地打印完整的有效搜索路径。
但是:搜索路径由-L
命令行上的选项指定的目录组成,然后是由SEARCH_DIR("...")
链接器脚本中的伪指令添加到搜索路径的目录。因此,如果您可以同时看到这两者,则可以进行计算,方法如下:
如果您ld
直接调用:
-L
选项是无论你说他们是。--verbose
选项。查找SEARCH_DIR("...")
指令,通常在输出顶部附近。(请注意,对于每次调用,ld
这些链接不一定都是相同的-链接器具有许多不同的内置默认链接器脚本,并根据各种其他链接器选项在它们之间进行选择。)如果您通过链接gcc
:
-v
选项传递给,gcc
以便向您显示如何调用链接器。实际上,它通常不会ld
直接调用,而是通过称为工具collect2
(位于其内部目录之一中)间接调用,该工具又会调用ld
。这将向您显示-L
正在使用的选项。-Wl,--verbose
到gcc
选项使之通过--verbose
通过对连接器,看到上面所描述的链接脚本。-T script
脚本时完全替换了ld的默认脚本,只看了我指向的位置。
我在Linux上为gcc和clang找到的最兼容的命令(感谢armando.sano):
$ gcc -m64 -Xlinker --verbose 2>/dev/null | grep SEARCH | sed 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g' | grep -vE '^$'
如果您给出-m32
,它将输出正确的库目录。
我的机器上的示例:
为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
为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
这个问题被标记为Linux,但是也许在Linux下也能正常工作?
gcc -Xlinker -v
在Mac OS X下,将打印:
@(#)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/
[...]
上面的-Xlinker
选项gcc
只是传递-v
给ld
。然而:
ld -v
不打印搜索路径。
-Lpath
。因此,@RaphaëlLondeix的答案更好。
/usr/local/..
这会导致缺少库错误,并且链接失败。我必须/usr/local
每次都重命名以排除该搜索路径。有没有简单的方法可以排除或覆盖/usr/local
路径?