关于 GCC 链接器的问题

Question

抱歉，因为目前我没有环境来亲自尝试和整理以下问题：

1) 假设我有四个库文件：libmylib_super.a 和 libmylib_super.so、mylib_dumb.a 和 mylib_dumb.so。在指定要链接的库时，以下方法之间有什么区别：

A)-l:libmylib_super.a
B) -llibmylib_super
C)-lmylib_super
D)-lmylib_dumb

2) 手册页中-static 的定义：

在支持动态的系统上 链接，这可以防止链接 共享库。在其他 系统，此选项无效。

此链接器选项与问题 #1 有什么关系吗？或者……他们会不会互相干扰？

谢谢。

--- 2009-12-28 编辑 ---

通过链接到 Boost date_time 库，我刚刚建立了我的环境并进行了一些试验。假设我有三个库文件：libboost_date_time-mt-d.a、libboost_date_time-mt-d.so.1.41.0、libboost_date_time-mt-d.so -> libboost_date_time-mt-d.so.1.41.0（符号链接）。

A.1) -l:libboost_date_time-mt-d.a ==> 链接正常，即使没有库文件，二进制也可以工作。
A.2) -l:libboost_date_time-mt-d.a 和 -static ==> 链接错误 /usr/bin/ld: cannot find -lm

C.1) -lboost_date_time-mt-d ==> 链接正常，二进制工作，但需要共享库文件。
C.2) -lboost_date_time-mt-d 和 -static ==> 链接错误 /usr/bin/ld: cannot find -lm

知道 A.2 和 C.2 中的错误吗？

此外，在 C.1 中运行程序时，似乎搜索名称为 libboost_date_time-mt-d.so.1.41.0 而不是 libboost_date_time-mt-d.so 的共享库文件。如果程序在没有确切版本库的系统上运行，那会不会很不方便？使用共享库时处理版本的实用方法是什么？

Answer 1

根据手册，

A) 在库路径中搜索完全命名为 libmylib_super.a 的文件（首先搜索共享库行为不适用）

B) 先在库路径中搜索名为 liblibmylib_super.so 的文件，然后是 liblibmylib_super.a和文件扩展名

C) 首先在库路径中搜索名为 libmylib_super.so 的文件，然后是 libmylib_super.a 或仅在使用 -static 时搜索名为 liblibmylib_super.so 的文件

D) 见 C)

请注意，B) 不起作用，因为它是链接器应该将 lib 前缀添加到库名称。

请注意，D) 不起作用，因为您的 mylib_dumb 不遵循命名约定。

见GNU Linker Manual：

-l 名称规范

--library=namespec

将 namespec 指定的存档或目标文件添加到要链接的文件列表中。此选项可以使用任意次数。如果 namespec 的格式为 :filename，ld 将在库路径中搜索名为 filename 的文件，否则它将在库路径中搜索名为 libnamespec.a 的文件。

在支持共享库的系统上，ld 也可以搜索 libnamespec.a 以外的文件。具体来说，在 ELF 和 SunOS 系统上，ld 将在目录中搜索名为 libnamespec.so 的库，然后再搜索名为 libnamespec.a 的库。 （按照惯例，.so 扩展名表示共享库。）请注意，此行为不适用于 :filename，它始终指定一个名为 filename 的文件。

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

查看 -( 选项以了解强制链接器多次搜索档案的方法。

您可以在命令行上多次列出同一个存档。

这种类型的存档搜索是 Unix 链接器的标准。但是，如果您在 AIX 上使用 ld，请注意它与 AIX 链接器的行为不同。