Linux系统下 连接器ld链接顺序的总结
时间:2014-11-01 01:34 来源:linux.it.net.cn 作者:it
原来ld对于链接一系列的库的顺序是很敏感的,不然会报undefined referenced 的函数符号错误,意思就是未找到函数定义。实际上库是能正确打开的。如果库libA.a依赖于库libB.a,那么连接器的参数应该ln -lA -lB, 必须这样写。不然就会错误。
这个看来是历史的遗留问题。说白了就是,如果你确定某个库不重要,就放到最后,也就是说,库的加载顺序是按顺序进行的,从左到右,优先级最高,这也是远古时代机器太破的原因,内在和硬盘包括CPU都是极其稀罕珍贵的。所以要你提前搞定哪些需要哪些不需要,一旦需要,就加载上去,不需要就不要加载上去。这样就可以解释上面的错误了,编译器加载到socketcomm后,发现还有依赖库,再往后找,木有咧,于是就错了。
也就是说,被依赖的尽量放到后面,让大家可以共用。
这就引申同来了另外一个问题,如果有多个库,使用了相同的函数名或者类名,结构体名称会怎么样?
可以使用nm和readelf、ldd等命令来查看你的库的依赖和符号表以及导出的函数符号等。这样就可以来验证上面的因为顺序造成的不同的编译结果。
把测试的库分成动、动;静、静;动静三种情况。
第一种情况:静静库都包含有相同的名字函数
代码如下: gcc -L./ main.c -lA -lB
编译报错,在multiple definition of `XXX‘。重复定义函数。
第二种情况:动动库
这个得看加载的顺序,上面说过,从左开始,按需加载。
代码如下: gcc main.c ./libB.so ./libA.so
代码如下: gcc main.c ./libA.so ./libB.so
这样的链接方式为隐式链接,或者说加载时链接,而前面的静态库为编译时连接。
也就是说,编译的顺序确定到底调用哪个库中的同名函数。
第三种情况:动动,但是是动态加载,而不上面的静态加载。
代码如下: gcc main.c -ldl ./libA.so ./libB.so
代码如下: gcc main.c -ldl ./libB.so ./libA.so
没有加链接选项时,跟第二种情况一样。加了L选项后,指定哪上加载哪个。
libB为静态链接!, libA为动态加载.
代码如下: gcc -L./ main.c -ldl –lB
动态库的库名显示的加载入编译选项中
代码如下: gcc -L./ main.c -ldl -lB ./libA.so
代码如下: gcc -L./ main.c -ldl ./libA.so -lB
(责任编辑:IT)
原来ld对于链接一系列的库的顺序是很敏感的,不然会报undefined referenced 的函数符号错误,意思就是未找到函数定义。实际上库是能正确打开的。如果库libA.a依赖于库libB.a,那么连接器的参数应该ln -lA -lB, 必须这样写。不然就会错误。 这个看来是历史的遗留问题。说白了就是,如果你确定某个库不重要,就放到最后,也就是说,库的加载顺序是按顺序进行的,从左到右,优先级最高,这也是远古时代机器太破的原因,内在和硬盘包括CPU都是极其稀罕珍贵的。所以要你提前搞定哪些需要哪些不需要,一旦需要,就加载上去,不需要就不要加载上去。这样就可以解释上面的错误了,编译器加载到socketcomm后,发现还有依赖库,再往后找,木有咧,于是就错了。 也就是说,被依赖的尽量放到后面,让大家可以共用。 这就引申同来了另外一个问题,如果有多个库,使用了相同的函数名或者类名,结构体名称会怎么样? 可以使用nm和readelf、ldd等命令来查看你的库的依赖和符号表以及导出的函数符号等。这样就可以来验证上面的因为顺序造成的不同的编译结果。 把测试的库分成动、动;静、静;动静三种情况。 第一种情况:静静库都包含有相同的名字函数
编译报错,在multiple definition of `XXX‘。重复定义函数。 第二种情况:动动库 这个得看加载的顺序,上面说过,从左开始,按需加载。
这样的链接方式为隐式链接,或者说加载时链接,而前面的静态库为编译时连接。 也就是说,编译的顺序确定到底调用哪个库中的同名函数。 第三种情况:动动,但是是动态加载,而不上面的静态加载。
没有加链接选项时,跟第二种情况一样。加了L选项后,指定哪上加载哪个。 libB为静态链接!, libA为动态加载.
动态库的库名显示的加载入编译选项中
|