通过环境变量告诉 ld 在哪里寻找目录答案

【问题标题】：Telling ld where to look for directories via an environment variable通过环境变量告诉 ld 在哪里寻找目录
【发布时间】：2011-01-14 15:46:31
【问题描述】：

我正在为一个班级评分 C 和 C++ 文件，这个作业使用 GSL 库。由于我的计算机没有 root 权限，我的 GSL 库安装在我的主目录中，因此我需要告诉编译器和链接器在哪里可以找到它。

当我自己编写程序时，这不是问题，因为我只是在 gcc 中添加了适当的 -L 和 -I 标志。

但是当我编译学生的文件时，我不想编辑他们的每一个 makefile。相反，我想将适当的目录放入环境变量中，以便无缝地发生。

为此，我已将以下变量与库一起导出或包含位置： C_INCLUDE_PATH、CPLUS_INCLUDE_PATH、LIBRARY_PATH 和 LD_LIBRARY_PATH

但是当我编译一个学生的项目时，用

gcc -Wall -o MC_thread MC_thread.c -lgsl -lgslcblas -lpthread -lm

我收到以下错误：

/usr/bin/ld: cannot find -lgsl
collect2: ld returned 1 exit status
make: *** [all] Error 1

我正在使用 gcc v 4.1.2。如果我使用 gcc v 4.4，我实际上没有收到错误，但我不知道为什么。我的链接器是：

ld -V
GNU ld version 2.17.50.0.6-12.el5 20061020.

【问题讨论】：

为他们使用的环境变量尝试 man ld 和 man ld.so。 LD_LIBRARY_PATH 可能会起作用。
我认为 LD_LIBRARY_PATH 仅由 ld.so 使用，而不是由 ld 使用。由于这是一个编译时错误，而不是运行时错误，我将重点介绍为什么 LIBRARY_PATH 不起作用。我要验证两件事，库文件是否具有正确的名称以及 LIBRARY_PATH 是否实际上是在 gcc 执行环境中定义的？
尝试使用 '-v' 选项运行 gcc 并从输出中发布完整的 ld 调用。

标签： c path shared-libraries ld

【解决方案1】：

您可以尝试使用环境变量 LIBRARY_PATH

来自man gcc（至少4.4版）

图书馆路径 LIBRARY_PATH 的值是以冒号分隔的目录列表，很像PATH。当配置为本机编译器时，GCC 会尝试搜索特殊链接器时指定的目录文件，如果使用 GCC_EXEC_PREFIX 找不到它们。使用链接 GCC 在搜索普通的时候也会用到这些目录 -l 选项的库（但使用 -L 指定的目录来第一的）。

然后在运行他们的程序时使用 LD_LIBRARY_PATH 让运行时链接器找到库。

【讨论】：

OP 说他正在使用 LIBRARY_PATH （自从您的帖子以来，它看起来不像是编辑。）

【解决方案2】：

我的建议是要求学生在他们的 makefile 中支持 CFLAGS 环境变量，否则他们会失败。 :) 然后你可以导出 CFLAGS="-Lwhatever"。

或者您可以使用 LD_LIBRARY_PATH。

【讨论】：

您可能指的是 LDFLAGS，因为 -l 和 -L 是链接器参数，而不是编译器阶段参数。但是，是的，我同意。没有这些变量的 Makefile 是没有用的。

【解决方案3】：

上面的很多答案都建议使用 LD_LIBRARY_PATH。但这是不正确的，因为这是动态（运行时）链接器的环境变量，而不是编译时链接器 ld。

这样做的正确方法是要求学生附加如下内容：

-L$(EXTRA_LINK_DIRECTORY)

在他们定义构建规则的地方的 Makefile 中。然后，当你编译时，执行如下操作：

导出 EXTRA_LINK_DIRECORY=/home/...

【讨论】：

【解决方案4】：

如果您使用的是 64 位机器，那可能就是问题所在。 OMM，gcc 4.1 不搜索 LIBRARY_PATH 中指定的路径，而是搜索 path/../lib64。您需要直接指定 -L，或者将目录符号链接到同一级别的 lib64，或者弄乱 gcc 规范。

见http://gcc.gnu.org/ml/gcc-help/2010-11/msg00360.html和Why does g++ look in LIBRARY_PATH/../lib64 and where is this documented?

（OMM，这确实适用于 gcc 4.5，没有任何麻烦，所以我猜他们稍后会修复它。）

【讨论】：

使用 spec 文件也没有多大帮助，因为让它只搜索 lib 意味着 gcc 找不到它的内部位，并且让它同时搜索 lib 和 lib64 意味着 gcc 吐出一堆它发现的不兼容的 32 位版本的警告。
大概就是这样！由于我自己安装了 GSL，因此我没有 lib/ 和 lib64/ 目录，而只有一个带有（64 位）库的位置，但没有预期的 lib64/ 名称。这是一个非常烦人的功能。我猜 gcc 4.4 和 4.5 有更好的行为