通过环境变量告诉 ld 在哪里查找目录

发布于 2024-08-20 22:00:06 字数 718 浏览 4 评论 0原文

我正在对课程的 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.

I'm grading C and C++ files for a class, and this assignment uses the GSL library. Since I don't have root permission on my computer, my GSL library is installed in my home directory, and thus I need to tell compilers and linkers where to find it.

This isn't a problem when I write a program myself, because I just add the appropriate -L and -I flags to gcc.

But when I'm compiling student's files, I don't want to edit every one of their makefiles. Instead, I want to put the appropriate directories into an environment variable, so that it happens seamlessly.

To this end, I've exported the following variables with the library or include locations:
C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH and LD_LIBRARY_PATH

But when I compile a student's project, with

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

I get the following error:

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

I'm using gcc v 4.1.2. I actually don't get the error if I use gcc v 4.4, but I have no clue why. My linker is:

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

一生独一 2024-08-27 22:00:06

您可以尝试使用 man gcc 中的环境变量 LIBRARY_PATH

(至少版本 4.4)

       LIBRARY_PATH
           The value of LIBRARY_PATH is a colon-separated list of directories,
           much like PATH.  When configured as a native compiler, GCC tries
           the directories thus specified when searching for special linker
           files, if it can't find them using GCC_EXEC_PREFIX.  Linking using
           GCC also uses these directories when searching for ordinary
           libraries for the -l option (but directories specified with -L come
           first).

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

You could try using the environment variable LIBRARY_PATH

From man gcc (at least version 4.4)

       LIBRARY_PATH
           The value of LIBRARY_PATH is a colon-separated list of directories,
           much like PATH.  When configured as a native compiler, GCC tries
           the directories thus specified when searching for special linker
           files, if it can't find them using GCC_EXEC_PREFIX.  Linking using
           GCC also uses these directories when searching for ordinary
           libraries for the -l option (but directories specified with -L come
           first).

And then then use LD_LIBRARY_PATH when you run their programs to to let the run-time linker find the libraries.

晌融 2024-08-27 22:00:06

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

正确的方法是要求学生

-L$(EXTRA_LINK_DIRECTORY)

在他们定义构建规则的 Makefile 中添加类似以下内容。然后,当编译时,执行如下操作:

export EXTRA_LINK_DIRECORY=/home/...

A lot of the answers above suggest the use of LD_LIBRARY_PATH. But this is incorrect since that is an environmental variable for the dynamic (runtime) linker, not the compile time linker ld.

The correct way to do this is to require the students to append something like:

-L$(EXTRA_LINK_DIRECTORY)

in their Makefile at the point at which they define the build rule. Then, when you compile, do something like:

export EXTRA_LINK_DIRECORY=/home/...

︶ ̄淡然 2024-08-27 22:00:06

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

请参阅 http://gcc.gnu.org/ml/gcc -help/2010-11/msg00360.html为什么 g++ 在 LIBRARY_PATH/../lib64 中查找,它在哪里记录?

(OMM,这确实适用于 gcc 4.5,没有任何混乱,所以我猜他们稍后修复。)

If you're on a 64-bit machine, that's probably the problem. OMM, gcc 4.1 doesn't search the paths specified in LIBRARY_PATH, but rather path/../lib64. You'll need to specify -L directly, or symlink the directory to lib64 at the same level, or mess with the gcc specs.

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

(OMM, this does work with gcc 4.5 without any messing around, so I'm guessing they fixed it later on.)

仅此而已 2024-08-27 22:00:06

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

或者您可以使用 LD_LIBRARY_PATH。

My advice is to require students to support a CFLAGS environment variable in their makefiles, Or else they fail. :) Then you can export CFLAGS="-Lwhatever".

Or you could use LD_LIBRARY_PATH.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文