关于GCC链接器的问题

shi*_*ing 5 linker gcc ld libraries

道歉,因为目前我没有环境来试验并自己解决以下问题:

1)假设我有四个库文件:libmylib_super.alibmylib_super.so,mylib_dumb.amylib_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==>链接OK,即使没有库文件,二进制文件仍可正常工作.
A.2)-l:libboost_date_time-mt-d.a带有-static==> 链接错误 /usr/bin/ld: cannot find -lm

C.1)-lboost_date_time-mt-d==>链接OK,二进制有效但需要共享库文件.
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.如果程序在没有库的确切版本的系统上运行,那会不会很不方便?在使用共享库时,处理该版本的实用方法是什么?

Gre*_*osz 9

根据手册,

A)在库路径中搜索确切命名的文件libmylib_super.a(首先搜索共享库行为不适用)

B)在库路径中搜索名为liblibmylib_super.sofirst 的文件,liblibmylib_super.a或者仅搜索名为liblibmylib_super.aif 的文件-static- 注意它是添加lib前缀和文件扩展名的链接器

C)搜索库路径文件名为libmylib_super.so第一则libmylib_super.a或仅搜索一个文件名为liblibmylib_super.so如果-static使用

D)见C)

请注意,B)将无法工作,因为它是应该lib为库名称添加前缀的链接器.

请注意,D)将不起作用,因为您mylib_dumb不遵循命名约定.

请参阅GNU链接器手册:

-l namespec

--library = namespec

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

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

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

请参阅 - (用于强制链接器多次搜索存档的方法的选项).

您可以在命令行上多次列出相同的存档.

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