g++:静态库和动态库应该以什么顺序链接?
假设我们有一个名为my_app"的主可执行文件，它使用了其他几个库:3 个库是静态链接的，另外 3 个是动态链接的.它们应该按什么顺序与my_app"相关联?
Let's say we got a main executable called "my_app" and it uses several other libraries: 3 libraries are linked statically, and other 3 are linked dynamically. In which order should they be linked against "my_app"?
但是这些应该按什么顺序链接呢?
But in which order should these be linked?
假设我们得到了依赖于 libSB 的 libSA(如在静态 A 中)和依赖于 libSB 的 libSC:
Let's say we got libSA (as in Static A) which depends on libSB, and libSC which depends on libSB:
libSA -> libSB -> libSC
和三个动态库:libDA ->libDB->libDC(libDA为基础，libDC为最高)
and three dynamic libraries:libDA -> libDB -> libDC (libDA is the basic, libDC is the highest)
这些应该按什么顺序链接?基本的第一个还是最后一个?
in which order should these be linked? the basic one first or last?
g++ ... -g libSA libSB libSC -lDA -lDB -lDC -o my_app
似乎是正确的顺序，但是是这样吗?如果任何动态库与静态库或其他方式之间存在依赖关系怎么办?
seems like the currect order, but is that so? what if there are dependencies between any dynamic library to a static one, or the other way?
推荐答案
在静态情况下，这并不重要，因为您实际上并没有链接静态库 - 您所做的只是将一些目标文件打包在一起档案.您只需编译目标文件，即可立即创建静态库.
In the static case, it doesn't really matter, because you don't actually link static libraries - all you do is pack some object files together in one archive. All you have to is compile your object files, and you can create static libraries right away.
动态库的情况比较复杂，有两个方面:
The situation with dynamic libraries is more convoluted, there are two aspects:
共享库的工作方式与静态库完全相同(共享段除外，如果它们存在的话)，这意味着，您可以做同样的事情 - 只要您拥有目标文件.这意味着例如来自 libDA 的符号将在 libDB 中显示为未定义
A shared library works exactly the same way as static library (except for shared segments, if they are present), which means, you can just do the same - just link your shared library as soon as you have the object files. This means for example symbols from libDA will appear as undefined in libDB
您可以在链接共享对象时在命令行中指定要链接的库.这与 1. 的效果相同，但将 libDB 标记为需要 libDA.
You can specify the libraries to link to on the command line when linking shared objects. This has the same effect as 1., but, marks libDB as needing libDA.
不同之处在于，如果使用前一种方式，则在链接可执行文件时，必须在命令行中指定所有三个库(-lDA、-lDB、-lDC).如果您使用后者，您只需指定 -lDC ，它会在链接时自动拉取其他人.请注意，链接时间就在您的程序运行之前(这意味着您可以获得不同版本的符号，甚至来自不同的库).
The difference is that if you use the former way, you have to specify all three libraries (-lDA, -lDB, -lDC) on the command line when linking the executable. If you use the latter, you just specify -lDC and it will pull the others automatically at link time. Note that link time is just before your program runs (which means you can get different versions of symbols, even from different libraries).
这一切都适用于 UNIX；Windows DLL 的工作方式完全不同.
This all applies to UNIX; Windows DLL work quite differently.
引用自 ld 信息手册.
链接器将仅搜索存档一次，在它所在的位置在命令行中指定.如果存档定义了一个符号，它是在某些对象中未定义出现在存档之前命令行，链接器将包括适当的文件(S)从档案.但是，未定义的符号在稍后出现的对象中命令行不会导致链接器再次搜索存档.
The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.
查看 `-(' 选项以了解强制方法用于搜索多个档案的链接器次.
See the `-(' option for a way to force the linker to search archives multiple times.
您可以列出多个相同的存档命令行的次数.
You may list the same archive multiple times on the command line.
这种类型的档案搜索是Unix 链接器的标准.然而，如果您在 AIX 上使用ld"，请注意它与行为不同AIX 链接器.
This type of archive searching is standard for Unix linkers. However, if you are using `ld' on AIX, note that it is different from the behaviour of the AIX linker.
这意味着:
在命令行中，任何依赖于其他库的静态库或对象都应该放在它之前.如果静态库相互依赖循环，你可以例如.使用 -( 命令行选项，或者将库放在命令行上两次 (-lDA -lDB -lDA).动态库的顺序无关紧要.
Any static library or object that depends on other library should be placed before it in the command line. If static libraries depend on each other circularly, you can eg. use the -( command line option, or place the libraries on the command line twice (-lDA -lDB -lDA). The order of dynamic libraries doesn't matter.
相关文章