我见过很多次，我们的一些模块链接了超过 100 个代码库以及系统和第三方库。

根据不同的链接器，HP/Intel/GCC/SUN/SGI/IBM/等，您可以获得未解析的函数/变量等，在某些平台上，您必须列出两次库。

在大多数情况下，我们使用库、核心、平台、不同抽象层的结构化层次结构，但对于某些系统，您仍然必须按照 link 命令中的顺序进行操作。

一旦你找到了解决方案，就把它记录下来，这样下一个开发人员就不必再次解决它了。

我的老讲师曾经说过，“高内聚和低耦合”，今天仍然如此。

GNU ld 链接器是所谓的智能链接器。它将跟踪前面的静态库使用的函数，从其查找表中永久删除那些未使用的函数。结果是，如果过早链接静态库，则该库中的函数在链接行的后面不再可用于静态库。

典型的 UNIX 链接器从左到右工作，因此将所有依赖库放在左侧，将满足这些依赖项的库放在链接行的右侧。您可能会发现某些库依赖于其他库，而其他库则依赖于它们。这就是它变得复杂的地方。当涉及到循环引用时，请修复您的代码！

_{（请参阅此答案的历史以获得更详细的文本，但我现在认为读者更容易看到真正的命令行）。}

---

以下所有命令共享的通用文件

// a depends on b, b depends on d
$ cat a.cpp
extern int a;
int main() {
  return a;
}

$ cat b.cpp
extern int b;
int a = b;

$ cat d.cpp
int b;

链接到静态库

$ g++ -c b.cpp -o b.o
$ ar cr libb.a b.o
$ g++ -c d.cpp -o d.o
$ ar cr libd.a d.o

$ g++ -L. -ld -lb a.cpp # wrong order
$ g++ -L. -lb -ld a.cpp # wrong order
$ g++ a.cpp -L. -ld -lb # wrong order
$ g++ a.cpp -L. -lb -ld # right order

链接器从左到右搜索，并随时记录未解析的符号。如果库解析符号，则它采用该库的目标文件来解析符号（在本例中为 b.o out of libb.a）。

静态库之间的依赖关系是相同的 - 首先需要符号的库，然后是解析符号的库。

如果一个静态库依赖于另一个库，但另一个库又依赖于前一个库，则存在一个循环。您可以通过用 和 括起来循环依赖库来解决此问题，例如（您可能需要转义括号，例如 和）。然后，链接器会多次搜索这些包含的库，以确保循环依赖项得到解决。或者，您可以多次指定库，以便每个库都位于彼此之前：。-(-)-( -la -lb -)-\(-\)-la -lb -la

链接到动态库

$ export LD_LIBRARY_PATH=. # not needed if libs go to /usr/lib etc
$ g++ -fpic -shared d.cpp -o libd.so
$ g++ -fpic -shared b.cpp -L. -ld -o libb.so # specifies its dependency!

$ g++ -L. -lb a.cpp # wrong order (works on some distributions)
$ g++ -Wl,--as-needed -L. -lb a.cpp # wrong order
$ g++ -Wl,--as-needed a.cpp -L. -lb # right order

这里是一样的 - 库必须遵循程序的目标文件。与静态库相比，这里的区别在于，您不需要关心库之间的依赖关系，因为动态库会自行整理它们的依赖关系。

最近的一些发行版显然默认使用链接器标志，该标志强制程序的目标文件位于动态库之前。如果传递了该标志，则链接器将不会链接到可执行文件实际不需要的库（并且它会从左到右检测到这一点）。我最近的 archlinux 发行版默认不使用此标志，因此它没有因未遵循正确的顺序而出现错误。--as-needed

在创建前者时省略 against 的依赖关系是不正确的。届时，您将需要在链接时指定库，但实际上并不需要整数本身，因此不应关心自己的依赖项。b.sod.soaabb

下面是一个示例，说明如果您错过了指定依赖项libb.so

$ export LD_LIBRARY_PATH=. # not needed if libs go to /usr/lib etc
$ g++ -fpic -shared d.cpp -o libd.so
$ g++ -fpic -shared b.cpp -o libb.so # wrong (but links)

$ g++ -L. -lb a.cpp # wrong, as above
$ g++ -Wl,--as-needed -L. -lb a.cpp # wrong, as above
$ g++ a.cpp -L. -lb # wrong, missing libd.so
$ g++ a.cpp -L. -ld -lb # wrong order (works on some distributions)
$ g++ -Wl,--as-needed a.cpp -L. -ld -lb # wrong order (like static libs)
$ g++ -Wl,--as-needed a.cpp -L. -lb -ld # "right"

如果你现在研究二进制文件有什么依赖关系，你会注意到二进制文件本身也依赖于 ，而不仅仅是它应该依赖的。如果以后依赖于另一个库，则需要重新链接二进制文件，如果这样做。如果其他人在运行时加载 use（考虑动态加载插件），调用也会失败。所以真的也应该是一个。libdlibblibblibbdlopen"right"wrong

链接顺序当然很重要，至少在某些平台上是这样。我见过以错误的顺序与库链接的应用程序崩溃（错误意味着 A 在 B 之前链接，但 B 依赖于 A）。

下面是一个示例，可以清楚地说明在涉及静态库时 GCC 的工作方式。因此，让我们假设我们有以下场景：

• myprog.o- 包含功能，取决于main()libmysqlclient
• libmysqlclient- 静态的，为了示例（当然，您更喜欢共享库，因为它很大）;在;并依赖于来自libmysqlclient/usr/local/liblibz
• libz（动态）

我们如何将其联系起来？（注意：使用 gcc 4.3.4 在 Cygwin 上编译的示例）

gcc -L/usr/local/lib -lmysqlclient myprog.o
# undefined reference to `_mysql_init'
# myprog depends on libmysqlclient
# so myprog has to come earlier on the command line

gcc myprog.o -L/usr/local/lib -lmysqlclient
# undefined reference to `_uncompress'
# we have to link with libz, too

gcc myprog.o -lz -L/usr/local/lib -lmysqlclient
# undefined reference to `_uncompress'
# libz is needed by libmysqlclient
# so it has to appear *after* it on the command line

gcc myprog.o -L/usr/local/lib -lmysqlclient -lz
# this works

您可以使用 -Xlinker 选项。

g++ -o foobar  -Xlinker -start-group  -Xlinker libA.a -Xlinker libB.a -Xlinker libC.a  -Xlinker -end-group 

几乎等于

g++ -o foobar  -Xlinker -start-group  -Xlinker libC.a -Xlinker libB.a -Xlinker libA.a  -Xlinker -end-group 

小心！

1. 组内的顺序很重要！ 下面是一个示例：调试库有一个调试例程，但非调试 库有一个相同的弱版本。您必须将调试库 FIRST，否则将解析为非调试版本。
2. 您需要在组列表中的每个库前面加上 -Xlinker

一个让我绊倒的快速提示：如果您将链接器调用为“gcc”或“g++”，那么使用“--start-group”和“--end-group”不会将这些选项传递给链接器——也不会标记错误。如果您的库顺序错误，它只会使未定义符号的链接失败。

您需要将它们写成“-Wl,--start-group”等，以告诉 GCC 将参数传递给链接器。

另一种替代方法是指定库列表两次：

gcc prog.o libA.a libB.a libA.a libB.a -o prog.x

这样做，您不必为正确的顺序而烦恼，因为引用将在第二个块中解析。

如果添加到链接器标志中，则它不关心它们处于哪个顺序，也不关心是否存在循环依赖项。-Wl,--start-group

在Qt上，这意味着添加：

QMAKE_LFLAGS += -Wl,--start-group

节省了大量的时间，而且它似乎并没有减慢链接的速度（无论如何，这比编译花费的时间要少得多）。

将文件放在哪里供链接器解析很重要。

一般规则是将文件放在被引用的位置，在文件被定义之前。symbolsymbol

要了解错误的原因，您必须了解链接器的工作原理：

• 传递给链接器的所有文件从左到右处理

• 链接器将未定义的符号从文件收集到未定义的池中 符号

• 如果存档中的对象无法解析池中的任何符号 未定义的符号，然后它就掉了

在案例中：

gcc -o libfunc2.so -shared -fPIC -lfunc1 func2.o

我们将定义符号的存档库放在引用它的目标文件之前。因此，libfunc1.a 不会解析任何符号并被丢弃。show1()func2.o

从 GCC -l 库选项：

在命令中编写此选项的位置会有所不同;链接器按指定的顺序搜索和处理库和对象文件。

因此foo.o -lz bar.o

在文件之后但在 之前搜索库。如果引用库中的函数，则可能无法加载这些函数。zfoo.obar.obar.oz