gcc - 为什么 gcc/ld 忽略 -L 设置？

Question

根据 ld(和用于扩展链接的 gcc)的手册页，如果 -L 选项出现在命令行上，它适用于 -l 指定的所有库，并优先于默认搜索位置。但是，这在我的链接步骤中不起作用。我在命令行上有这个:

-L/users/me/mylib -lpcre -lz

和/users/me/mylib 包含 libpcre.so 和 libz.so 的(副本)

这些库存在于系统的其他位置(虽然不一定是相同的版本)，我看到的(在 Linux 上使用 ldd，在 Mac 上使用 otool)是引用这些位置中的库的路径。其中一些位置在 LD_LIBRARY_PATH 上(我无法在我运行的构建环境中控制)并且似乎以某种方式优先选择了这些位置而不是我使用 -L 的显式设置。

需要说明的是，这是一个链接步骤问题，而不是运行时问题。网上有很多关于如何在执行时影响/覆盖库位置的信息，我对所有这些都很熟悉。从某种意义上说，我试图用 -L 做的是创建一个完全指定的设置。我知道我可以在 MacOS 上使用 install_name_tool 解决问题，但我真的很想了解为什么 -L 没有按照它声称的那样去做。

我使用 gcc -Wl,-v 了解到的一件事是 gcc 似乎将所有 LD_LIBRARY_PATH 目录转发到 ld。然而，它把它们放在我明确列出的那些之后，并且 man ld 说它们是按照它们出现在行中的顺序进行搜索的。

Answer 1

Just to be clear, this a link step problem and not a runtime problem.

根据您所描述的问题，我认为您对此不正确 - 这听起来像是一个运行时问题，您正在(有理由地)寻找可以在链接时使用的解决方案来解决问题你有在运行时。

我说这似乎不是链接问题的原因是，听起来您的链接正在按预期工作。 LD(或 GCC)没有提示链接，并且您的链接可执行文件正在生成得很好。您遇到的问题是，当您随后运行这些可执行文件时，加载程序正在查找您想要的库以外的库。 -L 标志在链接期间的目的是让链接器知道它可以在哪里找到合适的库来准备链接的二进制文件。这与加载程序在运行时搜索所需库的位置完全不同。

如您所说，您已经知道可以在运行时使用一些方法(例如更改 LD_LIBRARY_PATH)，通过更改加载程序搜索库的路径集来避免此问题，但您宁愿不必这样做，因为无论出于何种原因，您都不一定能够控制运行时环境，这很公平。

幸运的是，我相信有一种设施可以满足您的需求。查看名为 -rpath 的 ld 选项(完整文档请参阅 GNU ld man page)。基本上，如果您在链接期间使用 -rpath 选项添加路径，这些路径将存储在链接的可执行文件中，作为在运行时查找库的首选位置，其方式与包含时搜索库的方式大致相同在 LD_LIBRARY_PATH 中。这应该适用于 Linux 或 Mac OS X(至少从 10.5 开始)。

通过 gcc 将 -rpath 选项传递给 ld 需要使用 -Wl 选项来传递标志。要获得包含 ld -rpath/custom/path/to/libs 的 ld 命令行需要 gcc 调用，例如: gcc -Wl,-rpath,/custom/path/to/libs

简而言之，尝试替换您当前拥有的内容:-L/users/me/mylib -lpcre -lz

使用:-L/users/me/mylib -Wl,-rpath,/users/me/mylib -lpcre -lz

生成的可执行文件(或库)然后会将 /users/me/mylib 存储为查找库的位置，它应该找到 libpcre.so 和 libz.so 无需控制 LD_LIBRARY_PATH。