为什么gcc中'-l'选项的顺序很重要？[重复]

Question 1

我正在尝试编译一个使用udis86库的程序。实际上，我正在使用库用户手册中给出的示例程序。但是在编译时会产生错误。我得到的错误是：

example.c:(.text+0x7): undefined reference to 'ud_init'
example.c:(.text+0x7): undefined reference to 'ud_set_input_file'
.
.
example.c:(.text+0x7): undefined reference to 'ud_insn_asm'

我正在使用的命令是：

$ gcc -ludis86 example.c -o example

按照用户手册中的指示。

显然，链接器无法链接libudis库。但是，如果我将命令更改为：

$ gcc example.c -ludis86 -o example

它开始工作。因此，请有人解释第一个命令的问题是什么？

Question 2

因为这就是GNU链接器使用的链接算法的工作方式（至少在链接静态库时）。链接器是一个单通道链接器，一旦看到它们就不会重新访问库。

库是目标文件的集合（归档）。使用该-l选项添加库时，链接程序不会无条件地从库中获取所有目标文件。它仅采用当前需要的那些目标文件，即解析一些当前未解析（待定）符号的文件。之后，链接器完全忘记了该库。

当链接器处理输入的目标文件时，链接器会不断维护挂起的符号列表，从左到右一个接一个。在处理每个目标文件时，一些符号被解析并从列表中删除，其他新发现的未解析符号被添加到列表中。

因此，如果您通过使用包含了一些库-l，则链接程序将使用该库来解析尽可能多的当前挂起的符号，然后完全忽略该库。如果以后突然发现它现在需要该库中的一些其他目标文件，则链接器将不会“返回”该库以检索那些其他目标文件。已经为时已晚。

由于这个原因，在链接器命令行的后期使用-l选项始终是一个好主意，这样，当链接器到达该链接器时，它就可以可靠地确定所需的对象文件和不需要的对象文件。将选项作为链接器的第一个参数放置通常根本没有任何意义：在开始时，挂起的符号列表为空（或更准确地说，由单个符号组成），这意味着链接器不会从中获取任何内容图书馆。-l-lmain

在你的情况，你的目标文件example.o包含对符号的引用ud_init，ud_set_input_file等接头应首先接收目标文件。它将这些符号添加到未决符号列表中。之后，您可以使用-l选项添加库：-ludis86。链接器将搜索您的库并从中获取所有可解析那些未决符号的内容。

如果将-ludis86选项首先放在命令行中，则链接器将有效地忽略您的库，因为在开始时它并不知道将需要它ud_init，ud_set_input_file等等。稍后，在处理example.o时它将发现这些符号并将它们添加到挂起的符号清单。但是这些符号将一直无法解析到最后，因为它们-ludis86已经被处理（有效地被忽略了）。

有时，当两个（或多个）库以循环方式互相引用时，一个库甚至可能需要对-l同一库使用两次该选项，以使链接程序有两次机会从该库中检索必要的目标文件。

Question 3

我前一段时间也遇到过同样的问题。最重要的是，gnu工具不会总是在库列表中“向后搜索”以解决丢失的符号。简单修复是以下任何一种：

只需按依赖关系顺序指定libs和objs（如您在上面发现的）
或者，如果您具有循环依赖关系（其中libA引用libB中的一个函数，而libB引用libA中的一个函数），则只需在命令行上两次指定lib。这也是手册页建议的内容。例如
```
gcc foo.c -lfoo -lbar -lfoo
```
使用-(和-)参数可指定一组具有此类循环依赖性的档案。请参阅GNU链接器手册中的--start-group和--end-group。有关更多详细信息，请参见此处。

当使用选项2或3时，可能会引入性能成本。如果您没有太多链接，那就没关系了。

Question 4

或使用重新扫描

从《Oracle Solaris 11.1链接器和库指南》的第41页起：

档案之间可能存在相互依赖性，因此必须通过从另一档案中提取成员来解决从一个档案中提取成员的问题。如果这些依赖关系是循环的，则必须在命令行上重复指定档案，以满足先前的引用。

$ cc -o prog .... -lA -lB -lC -lA -lB -lC -lA

重复存档规范的确定和维护可能很繁琐。

-z rescan-now选项使此过程更简单。当在命令行上遇到-z rescan-now选项时，链接编辑器会立即处理该选项。在此选项之前，已从命令行处理过的所有存档都将立即重新处理。此处理尝试找到其他解析符号引用的存档成员。存档重新扫描将继续进行，直到发生遍历存档列表的情况，其中没有新成员被提取。前面的示例可以简化如下。

$ cc -o prog .... -lA -lB -lC -z rescan-now

或者，可以使用-z rescan-start和-z rescan-end选项将相互依赖的归档分组到一个归档组中。当在命令行上遇到结束定界符时，链接编辑器会立即重新处理这些组。对在组中找到的归档进行重新处理，以尝试查找可解决符号引用的其他归档成员。存档重新扫描将继续进行，直到发生遍历存档组的情况，在该存档组中不会提取新成员。使用归档组，可以将前面的示例编写如下。

$ cc -o prog .... -z rescan-start -lA -lB -lC -z rescan-end