Joh*_*itb 540
(请参阅此答案的历史记录以获取更详细的文本,但我现在认为读者更容易看到真正的命令行).
以下所有命令共享的公共文件
$ 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
链接器从左向右搜索,并记录未解析的符号.如果库解析符号,它将获取该库的目标文件来解析符号(在本例中为libb.a).
静态库相互依赖的工作方式相同 - 需要符号的库必须是第一个,然后是解析符号的库.
如果静态库依赖于另一个库,但另一个库再次依赖于前一个库,则存在一个循环.你可以通过用-(和封闭循环相关的库来解决这个问题-),例如-( -la -lb -)(你可能需要逃避parens,例如-\(和-\)).然后,链接器会多次搜索这些封闭的lib,以确保解析循环依赖关系.或者,您可以多次指定库,因此每个库都在彼此之前:-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
它在这里是一样的 - 库必须遵循程序的目标文件.这里与静态库的不同之处在于,您不必关心库之间的依赖关系,因为动态库本身会对其依赖关系进行排序.
最近的一些发行版显然默认使用--as-needed链接器标志,这会强制程序的目标文件位于动态库之前.如果传递了该标志,则链接器将不会链接到可执行文件实际不需要的库(并且它从左到右检测到它).我最近的archlinux发行版默认不使用此标志,因此不会因为没有遵循正确的顺序而给出错误.
在创建前者时省略b.so反对的依赖是不正确d.so的.当链接时a,您将需要指定库,但a实际上并不需要整数b本身,因此不应该关心b自己的依赖关系.
以下是您错过指定依赖项的含义示例 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"
如果您现在查看二进制文件具有哪些依赖关系,您会注意到二进制文件本身也依赖于它libd,而不仅仅是libb它应该如此.如果libb以后依赖于另一个库,则需要重新链接二进制文件,如果这样做的话.如果其他人在运行时加载libb使用dlopen(想想动态加载插件),调用也会失败.所以"right"真的应该是一个wrong.
cas*_*der 98
GNU ld链接器是所谓的智能链接器.它将跟踪前面的静态库使用的函数,永久地抛弃那些未在其查找表中使用的函数.结果是,如果过早链接静态库,那么稍后链接行上的静态库将不再提供该库中的函数.
典型的UNIX链接器从左到右工作,因此将所有依赖库放在左侧,将满足这些依赖性的库放在链接行的右侧.您可能会发现某些库依赖于其他库,而同时其他库依赖于它们.这是它变得复杂的地方.谈到循环引用,修复代码!
Lum*_*umi 52
这是一个示例,用于说明在涉及静态库时GCC的工作原理.所以我们假设我们有以下场景:
myprog.o- 包含main()功能,依赖于libmysqlclientlibmysqlclient- 静态,为了这个例子(你更喜欢共享库,当然,因为它libmysqlclient是巨大的); in /usr/local/lib; 并依赖于来自的东西libzlibz (动态)我们如何链接这个？(注意:使用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
Sva*_*Lop 28
如果添加-Wl,--start-group到链接器标志,它不关心它们在哪个顺序或者是否存在循环依赖关系.
在Qt上这意味着添加:
QMAKE_LFLAGS += -Wl,--start-group
节省了大量的时间,它似乎没有减慢连接速度(这比编译所花费的时间少得多).
另一种方法是两次指定库列表:
gcc prog.o libA.a libB.a libA.a libB.a -o prog.x
这样做,您不必打扰正确的序列,因为参考将在第二个块中解析.
一个让我感到困惑的快速提示：如果您将链接器调用为“gcc”或“g++”，那么使用“--start-group”和“--end-group”不会将这些选项传递给链接器——它也不会标记错误。如果您的库顺序错误，它只会使带有未定义符号的链接失败。
您需要将它们写为“-Wl,--start-group”等，以告诉 GCC 将参数传递给链接器。
小智 5
您可以使用-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
小心!
我见过很多这样的情况，我们的一些模块链接了超过 100 个代码库以及系统和第三方库。
\n\n根据不同的链接器 HP/Intel/GCC/SUN/SGI/IBM/etc，您可能会获得未解析的函数/变量等，在某些平台上您必须列出库两次。
\n\n在大多数情况下，我们使用库、核心、平台、不同抽象层的结构化层次结构，但对于某些系统，您仍然必须使用链接命令中的顺序。
\n\n一旦您找到了解决方案，请将其记录下来，这样下一个开发人员就不必再次解决它。
\n\n我的老讲师曾经说过，“高内聚低耦合”，今天仍然如此。
\n