linux - 为什么 -r 选项(可重定位)使 ld 找不到任何库？

Question

使用 GNU ld 2.21 运行 Debian/Linux x86_64。

很简单，如果我链接

ld -o main main.o /usr/lib/crti.o /usr/lib/crt1.o /usr/lib/crtn.o -lc -lm

它有效，但是当我链接到

ld -r -o main1.o main.o /usr/lib/crti.o /usr/lib/crt1.o /usr/lib/crtn.o -lc -lm

它提示

ld: cannot find -lc
ld: cannot find -lm

我实际上并不是在尝试以这种方式编译代码，而是在尝试弄清楚为什么其他人对库是否存在的测试不起作用。 (因此我不太明白 ld 是怎么回事...通常我只是使用 GCC 链接)

为什么告诉 ld 以可重定位的方式链接会使它突然找不到库？如果我只是想测试-lm是否存在，除了

我还应该做什么

ld -r -lm

这样它会找到图书馆？

如果您想查看我正在处理的源代码，可以在这里下载:https://github.com/jeremysalwen/ESPS (注意，第一次commit是原来的源码，后面的commit是我个人修改的。)

Answer 1

苹果电脑

在 MacOS X 上，ld 的手册页对 -r 选项非常明确:

-r Merges object files to produce another mach-o object file with file type MH_OBJECT.

因此，如果您使用的是 MacOS X，问题在于 -lm 不是 Mach-O 目标文件，-lc 也不是。但是，理论上，如果您有目标文件 main.o、obj1.o 和 obj2.o，并且您可以:

cp obj1.o ./-lm
cp obj2.o ./-lc
ld -r -o main1.o main.o -lm -lc

那么它可能会起作用。实际上，它不会，在您得到的错误中:

ld: warning: unexpected dylib (/usr/lib/libm.dylib) on link line
ld: warning: unexpected dylib (/usr/lib/libc.dylib) on link line

然而，运行:

ld -r -o main1.o -arch x86_64 main.o obj1.o obj2.o

加载程序没有任何提示。

Linux

在 Linux 上，ld 的手册页不太明确，但是说:

-i Perform an incremental link (same as option -r).

-r
--relocatable

Generate relocatable output---i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking. As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file’s magic number to "OMAGIC". If this option is not specified, an absolute file is produced. When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur.

When an input file does not have the same format as the output file, partial linking is only supported if that input file does not contain any relocations. Different output formats can have further restrictions; for example some "a.out"-based formats do not support partial linking with input files in other formats at all.

This option does the same thing as -i.

字里行间，这也获取目标文件并将它们转换为目标文件；它不会将库添加到组合中。如果您考虑一下，目标文件不会创建包含对库的引用。

因此，虽然在使用 -r 选项时可能有一些平台可以为链接器(加载器)指定库，但在其他平台上则不能。

解决方法

最初的问题是确定库是否存在。为什么不模仿 autoconf 的作用，并创建一个 main.c，它会优先包含对库中定义的符号的引用，但它可以简单地包含:

int main(void){return 0;}

并用 C 编译器编译和链接它:

cc -o main main.c -lm -lc

如果它不起作用，那么其中一个库丢失了。如果您已经检查过 -lc 存在，那么您可以推断 -lm 缺失。