linker - 链接时:使用-l标志或仅将归档作为输入

Question

我在问题Linking a static library into Boost Python (shared library) - Import Error中概述了将静态库stxxl链接到共享库时遇到的一些问题

我使用的命令是

g++ -Wall -pthread -march=i686 -I/home/zenna/Downloads/stxxl-1.3.0/include -include stxxl/bits/defines.h -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I /home/zenna/local/include/ -I /usr/include/python2.6/ -fPIC -c partition.cpp -o obj/Partition_wrap.o

并链接:

g++  -shared -lboost_python -L/home/zenna/local/lib/ -L/home/zenna/Downloads/stxxl-1.3.0/lib/bk/ -Wall -pthread -L/home/zenna/Downloads/stxxl-1.3.0/lib -lstxxl -o lib/fast_parts.so obj/Partition_wrap.o 

使用nm我发现丢失的符号在最终的输出共享库中，但是类型为“U”的 undefined 。

然后，我将链接命令更改为不仅使用-lstxxl，而且还将整个存档文件添加为链接器的另一个输入

这样新命令是(结尾处的差异)

++-共享的-lboost_python -L / home / zenna / local / lib / -L / home / zenna / Downloads / stxxl-1.3.0 / lib / bk / -Wall -pthread -L / home / zenna / Downloads / stxxl -1.3.0 / lib -lstxxl -o lib / fast_parts.so obj / Partition_wrap.o obj / libstxxl.a

据我所知，这解决了这个问题。

然后我的问题是 ，使用-l标志和将归档文件添加为输入之间有什么区别？为什么以前的方法会导致 undefined 的符号？

Answer 1

我认为您遇到的问题是您在目标文件之前指定了-lstxxl。将libstxxl.a放在末尾时，将再次读取它的符号，并解析 undefined 的符号。您可以尝试将其移动到obj/Partition_wrap.o之前，并检查它是否会导致 undefined 的符号。

来自man ld
ld -o /lib/crt0.o hello.o -lc

这告诉ld产生一个名为output的文件，其结果是将文件“/lib/crt0.o”与“hello.o”和库“libc.a”链接在一起，
这将来自标准搜索目录。 (请参阅下面有关-l选项的讨论。)

ld的某些命令行选项可以在命令行的任何位置指定。但是，选项引用文件，例如
作为-l或-T，导致在相对于目标文件的命令行中选项出现的位置读取文件
其他文件选项。

非选项参数是要链接在一起的目标文件或归档。它们可能跟随，先行或与
命令行选项，但不得在选项及其自变量之间放置目标文件自变量。

-l namespec

链接器仅在命令行上指定的位置搜索一次存档。如果存档定义了
在命令行中存档之前出现的某些对象中 undefined 的符号，链接器将包含
存档中的适当文件。但是，稍后出现在命令行中的对象中 undefined 的符号将不会导致
链接器再次搜索文件。

尽管没有提到很清楚，但给链接器提供文件链接的两种方式似乎没有什么区别。