当存在`LD_LIBRARY_PATH`时，使用`-L`有什么意义？

Question

在阅读this question后，我的第一反应是用户没有看到错误，因为他用-L指定了库的位置。

但是，显然，-L选项仅影响链接器的外观，并且在尝试运行已编译的应用程序时不会影响加载器的外观。

我的问题是-L的重点是什么？既然你无法运行你的二进制文件，除非你在LD_LIBRARY_PATH中有正确的目录，为什么不把它们放在那里，然后放弃-L，因为链接器看起来自动LD_LIBRARY_PATH？

Answer 1

可能是您正在进行交叉编译，并且链接器的目标是您自己以外的系统。例如，MinGW可用于在Linux上编译Windows二进制文件。这里-L将指向链接所需的DLL，LD_LIBRARY_PATH将指向链接器运行所需的任何库。这允许编译和链接不同的体系结构，OS ABI或处理器类型。

在尝试构建特殊目标时也很有用。我可能会将一个静态版本的程序与一个不同的静态库链接起来。这是Linux From Scratch的第一步，在主系统上创建一个单独的迷你环境，成为chroot监狱。

Answer 2

设置LD_LIBRARY_PATH将影响您为构建代码而运行的所有命令（包括编译器本身）。

这通常是不可取的（例如，您可能不希望编译器在编译时运行调试/检测库 - 它甚至可能会破坏您的编译）。

使用-L告诉编译器在哪里查看LD_LIBRARY_PATH以影响运行时链接。

Answer 3

构建二进制文件和运行二进制文件是两个完全独立且无关的进程。您似乎建议运行环境应该影响建筑环境，即您似乎假设某些设置（帐户，机器）中的代码构建稍后将在同一设置中运行。我觉得这个假设很奇怪。我甚至会说，在大多数情况下，建筑和跑步都是在不同的环境中完成的。我实际上更喜欢我的编译器不要从这些编译器调用的环境中得出关于未来运行环境的任何假设。查看建筑环境的LD_LIBRARY_PATH将是一个重要的禁忌。

Answer 4

其他答案都很好，但是没有人提到过静态库。大多数情况下，当您使用-L时，您在构建树中本地构建的静态库不打算安装，而且它与LD_LIBRARY_PATH无关。

Answer 5

Solaris上的编译器支持-R /runtime/path/to/some/libs，它添加了运行时链接程序搜索库的路径。在Linux上，-Wl,-rpath,/runtime/path/to/some/libs可以实现同样的目标。它将-rpath /runtime/path/to/some/libs选项传递给ld。 GNU ld也支持-R /path/to/libs与其他ELF链接器的兼容性，但应避免这种情况，因为-R通常用于将符号文件指定为GNU ld。