最近两周在封装一个简易的发邮件函数接口时，在编译成单个静态库后，同其他目标模块进行链接时出现了诸如函数未定义或多重定义的错误，在弄清了其中的缘由后，自己整理了下内容和可能原因的分析……
1）静态库和动态库
■ 基础知识省略……
■ 静态库的生成 && 链接
ar rc libmylib.a from1.o from2.o→gcc -o output main.c -L. -lmyhello
■ 动态库的生成 && 链接
gcc -fPIC -Wall -c from1.c → gcc -shared -fPIC -o libmylib.so from1.o
-fPIC：表示编译为位置独立的代码 → 详细的见结尾的推荐内容
＼ -L.：表示要连接的库在当前目录中
-lmyhello：编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称
LD_LIBRARY_PATH：这个环境变量指示动态连接器可以装载动态库的路径。
2）下面是网上查找的…… 写的不错
摘自：http://www.linuxdiyf.com/viewarticle.php?id=182131（陈运文）来自CSDN博客
-
- Linux gcc链接规则：
-
- 链接的时候查找顺序是:
- -L指定的路径,从左到右依次查找由环境变量 LIBRARY_PATH 指定的路径,使用":"分割从左到右依次查找/etc/ld.so.conf 指定的路径顺序/lib和/usr/lib（64位下是/lib64和/usr/lib64)
-
- 动态库调用的查找顺序:
- ld的-rpath参数指定的路径, 这是写死在代码中的ld脚本指定的路径LD_LIBRARY_PATH 指定的路径/etc/ld.so.conf 指定的路径/lib和/usr/lib(64位下是/lib64和/usr/lib64)
-
- 一般情况链接的时候我们采用-L的方式指定查找路径, 调用动态链接库的时候采用LD_LIBRARY_PATH的方式指定链接路径。
- 另外注意一个问题,就是只要查找到第一个就会返回,后面的不会再查找。比如-L./A -L./B -lx 在A中有libx.a B中有libx.a和libx.so, 这个时候会使用在./A的libx.a 而不会遵循动态库优先的原则,因为./A是先找到的,并且没有同名动态库存在。
- 对于动态链接库，实际的符号定位是在运行期进行的。在编译.so的时候，如果没有把它需要的库和他一起进行联编，比如libx.so 需要使用uldict, 但是忘记在编译libx.so的时候加上-luldict的话，在编译libx.so的时候不会报错，因为这个时候libx.so被认为是一个库，它里面存在一些不知道具体实现的符号是合法的，是可以在运行期指定或者编译另外的二进制程序的时候指定。
- 如果是采用g++ -Lpath -lx 的方式进行编译，链接器会发现所需要的uldict的符号表找不到从而报错，但是如果是程序采用dlopen的方式载入，由于是运行期，这个程序在这个地方就直接运行报错了。另外还有一种情况就是一个对外的接口在动态库中已经声明定义了，但是忘记实现了，这个时候也会产生类似的错误。如果在运行期报出这样的错误，就要注意是否是由于某些库没有链接进来或者某些接口没有实现的原因产生
-
- 有了上述基础，不难总结出，undefined reference error错误的原因可能来自以下几方面：
-
- 1 没有指定对应的库（.o/.a/.so）
- 使用了库中定义的实体，但没有指定库（-lXXX）或者没有指定库路径（-LYYY），会导致该错误,
-
- 2 连接库参数的顺序不对
- 在默认情况下,对于-l 使用库的要求是越是基础的库越要写在后面,无论是静态还动态 →具体原因见4）
-
- 3 gcc/ld 版本不匹配
- gcc/ld的版本的兼容性问题,由于gcc2 到 gcc3大版本的兼容性存在问题(其实gcc3.2到3.4也一定程度上存在这样的问题) 当在高版本机器上使用低版本的机器就会导致这样的错误, 这个问题比较常见在32位的环境上, 另外就在32位环境不小心使用了64位的库或者反过来64位环境使用了32位的库.
-
- 4 C/C++相互依赖和链接
- gcc和g++编译结果的混用需要保证能够extern "C" 两边都可以使用的接口,在我们的64位环境中gcc链接g++的库还需要加上 -lstdc++,具体见前文对于混合编译的说明
-
- 5 运行期报错
- 这个问题基本上是由于程序使用了dlopen方式载入.so, 但.so没有把所有需要的库都链接上,具体参加上文中对于静态库和动态库混合使用的说明
3）典型的错误提示及原因分析
① 错误提示“first defined here ... multiple definition of ”
→ 原因是在多次包含某个头文件时（如:swf.h）时重复定义了全局变量或函数
■ 解决方法1 → 在swf.c中申明某个变量但不初始化， 然后在swf.h头文件中，在该变量申明前加上extern
而在其他需要使用该全局变量的文件中，直接包含swf.h就行
→ 具体的原因涉及到链接器处理全局变量和函数的三个原则， 见后文5）
■ 解决方法2 → 在某个.h头文件中加入防止多次重复定义的宏判断符号
#ifndef XXX
#define XXX
......
#endif
② gcc main.c -lswf.a -o test → 错误提示”/usr/bin/ld: cannot find -lswf.a“
★ 提示ld链接错误，说找不到文件， 因为linker默认的是从/user/bin/ld加载库的（在没有指定路径的前提下）
③ gcc main.c ./swf.a -o test → 依旧提示”/usr/bin/ld: cannot find“
★ 也可用L指定库的路径，具体原因见4）
④ gcc -c main.c → gcc -o test main.o ./swf.a → 这个就能编译成功了，
这个遵从的规则和第2）部分说的是一样的，具体原因见4）
4）静态库链接原理的简单阐述
编译生成一个可执行目标文件，主要包括编译 && 链接， 编译生成的是可重定位目标文件
（共享目标文件之类的不在这个讨论范围内）， 最近linker在进行链接时按照如下的方法！
以命令gcc -o swf test1.o test2.o ... test3.o ./lib1.a ./lib2.a ./lib3.a ... ./libn.a 为例
■ 首先，linker划定三个集合：
A -- 用来放置用于生成swf执行文件的可重定位目标文件(.o)
X -- 记录在前面.o文件中出现的“符号引用”（仅没有找到对应的符号定义的，即符号定义不在集合Y中）
符号定义和引用，可以简单的分别理解为对全局变量（函数）的定义和引用（当然这个不准确）
Y -- 记录前面.o文件中出现的所有的“符号定义”
■ linker按从左到右的顺序依次读取输入文件 test1.o test2.o ... ./lib1.a ... ./libn.a
按照读入文件的格式.o还是.a不同，按不同的方式处理
★ 若是.o 文件，将.o添加到A中，再按照规则修改集合 X 和 Y，然后继续读入下一个输入文件
★ 若是.a 文件，则参照集合X依次在.a的成员目标模块（可简单的理解.a就是多个.o ）中查找对应的“符号定义”
每找到一个，则将对应的成员目标模块（.o）添加到A中，
再修改集合X和Y（模块里新出现的符号定义和符号引用也要对应添加到X Y中） 然后处理下一个
■ 按照上述方式循环处理，当通过gcc 所有的输入文件都处理完后，若X是不是空集，则会报链接失败的错误提示的
若为空集，则按照集合A进行重定位生成可执行目标文件
这样前面说先的“cannot find”错误提示就很容易理解了，也能理解“越基础的库越放在后面”的原因
详细的论述，见《深入理解计算机系统》第七章 链接 pdf电子版第483页， 自己论述的比较差
5）linker对多重定义全局符号的处理
■ 规则1→不允许有多个强符号
■ 规则2→有一个强符号和多个弱符号，则选择强符号
■ 规则3→有多个若符号，则从其中任选一个
★ 弱符号可以简单的理解为“只声明但没有初始化的全局变量（或函数）” ， 强符号相反
所以在①的解决方法1中，用了规则三，从而没有出现多重定义，当出现了多个强符号时，就会报①的错误！！！
详细的论述，见《深入理解计算机系统》第七章 链接 pdf电子版第478页， 自己论述的比较差
最后《深入理解计算机系统》pdf的下载地址，中文版的，带书签的！
http://download.csdn.net/detail/wuzhimang/7663921
扫一扫
4941
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
