【转】编译，链接与库的使用(2)

静态库和动态库的混合编译

目前我们多数的库都是以静态库的方式提供，但是现在有许多地方出于运维和升级的考虑使用了许多动态链接库，这样不可避免的出现了大量的静态库与动态库的混合使用，经常会出现一些奇怪的错误，使用的时候需要有所关注

对于一般情况下，只要静态库与共享库之间没有依赖关系，没有使用全局变量（包括static变量)，不会出现太多的问题，下面以出现的问题作例子来说明使用的注意事项。

baidugz与zlib的冲突

具体的说明可以参看wiki LibBaidugz baidugz 是百度早期用来解压压缩网页，可以自动识别多数的网页压缩格式具有一定的容错性，但是由于baidugz是早期zlib版本直接修改而来，出现与系统中版本不一致的时候就可能导致问题。

在 /usr/lib64/ 下可以看到 libz.so, 我们在直接使用系统zlib的时候多是在链接的时候加上 -lz 就可以了。程序在运行的时候会直接到系统的目录下去寻找libz.so,并且在运行期被载入。

早 期的zlib代码中有一部分函数和变量，虽然没有通过zlib.h对外公开，但是还是采用了extern的方式被其他的.c文件使用(这里涉及到一个问题 就是一个源码中的变量或接口要被同一个库中其它地方使用，只能被extern，但extern 后就意味着可以被其它任意使用这个库的程序看到和使用, 无论是否在对外接口中声明), 还有个别接口可以使用static但没有使用static。 这部分对内公开（实际上对外也公开了）的接口, 在baidugz的修改过程中没有被修改，在后来升级64位版本的时候，由于系统中的zlib与baidugz使用的zlib相差过大，zlib在本身的 升级过程中也没有过多的考虑这个问题(它假设不会有并存的情况), 导致在链接的过程出现错误.

在编写动态库的过程中，可以static的函数即使没有暴露在头文件也需要尽量static,避免和外界冲突。那种没有对外公开接口就无所谓加不加static的观点是存在一定风险的.

小提示：

有 些程序使用 using namespace {} 这样的匿名命名空间来规避冲突的问题，从编译器角度而言，在代码中使用确实不会产生冲突。 不过采用dlopen的方式却还是可以通过强制获取符号的方式运行在共享库中使用using namespace {}包含起来的函数，但static的函数是不能被dlopen方式强制获取的。

地址无关代码

在64位下编译动态库的时候，经常会遇到下面的错误

/usr/bin/ld: /tmp/ccQ1dkqh.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC

提示说需要-fPIC编译，然后在链接动态库的地方加上-fPIC的参数编译结果还是报错，需要把共享库所用到的所有静态库都采用-fPIC编译一边才可以成功的在64位环境下编译出动态库。

这里的-fPIC指的是地址无关代码

这 里首先先说明一下装载时重定位的问题，一个程序如果没有用到任何动态库，那么由于已经知道了所有的代码，那么装载器在把程序载入内存的过程中就可以直接安 装静态库在链接的时候定好的代码段位置直接加载进内存中的对应位置就可以了。但是在面对动态的库的时候 ，这种方式就不行了。假设需要载入共享库A,但是在编译链接的时候使用的共享库和最后运行的不一定是同一个库，在编译期就没办法知道具体的库长度，在链接 的时候就没办法确定它或者其他动态库的具体位置。另一个方面动态库中也会用到一些全局的符号，这些符号可能是来自其他的动态库，这在编译器是没办法假设的 （如果可以假设那就全是静态库了)

基于上面的原因，就要求在载入动态库的时候对于使用到的符号地址实现重定位。在实现上在编译链接的时候不做重定位操作，地址都采用相对地址，一但到了需要载入的时候，根据相对地址的偏移计算出最后的绝对地址载入内存中。

但是这种采用装载时重定位的方式存在一个问题就是相同的库代码（不包括数据部分）不能在多个进程间共享（每个代码都放到了它自己的进程空间中）,这个失去了动态库节省内存的优势。

为了解决这个问题，ELF中的做法是在数据段中建立一个指向那些需要被使用(内部的位置无关简单采用相对地址访问就可以实现)的地址列表(也被称为全局偏移表,Global offset table, GOT). 可以通过GOT相对应的位置进行间接引用.

对 于我们的32位环境来说, 编译时是否加上-fPIC, 都不会对链接产生影响, 只是一份代码的在内存中有几个副本的问题(而且对于静态库而言结果都是一样的).但在64位的环境下装载时重定位的方式存在一个问题就是在我们的64位环 境下用来进行位置偏移定位的cpu指令只支持32位的偏移, 但实际中位置的偏移是完全可能超过64位的,所以在这种情况下编译器要求用户必须采用fPIC的方式进行编译的程序才可以在共享库中使用

从理论上来说-fPIC由于多一次内存取址的调用,在性能上会有所损失.不过从目前的一些测试中还无法明显的看出加上-fPIC后对库的性能有多大的损失,这个可能和我们现在使用的机器缓存以及大量寄存器的存在相关.

小提示：

1. -fPIC与-fpic 上面的介绍可以看到，gcc要使用地址无关代码加上-fPIC即可，但是在gcc的手册中我们可以看到一个-fpic(区别在一个大写一个小写)的参数， 从功能上来说它们都是一样的。-fpic在一些特定的环境中（包括硬件环境)可以有针对性的进行优化，产生更小更快的代码, 但是由于受到平台的限制，像我们的编译环境，开发环境，运行环境都不完全统一的情况下面使用fpic有一定未知的风险，所有决大多数情况下我们使用 -fPIC来产生地址无关代码。
2. 共享内存效率

共享内存在只读的情况下性能和读普通内存是一样的(如果不算第一载入的消耗），而且由于是多个进程共享对cpu cache还显的相对友好。 可以参见 mmap性能

同时存在静态库和动态库

前 面提到编译动态库的时候有提到编译动态库可以像编译静态库那样采用-Lpath -lxx的方式进行, 但这里存在一个问题,如果在path目录下既有动态库又有静态库的时候的行为又是什么样地? 事实上在这种情下, 链接器优先选择采用动态库的方式进行编译.比如在同一目录下存在 libx.a 和 libx.so, 那么在链接的时候会优先选择libx.so进行链接. 这也是为什么在com组维护的第三方库(third, third-64)中绝大多数库的产出物中只有.a的存在, 主要就是为了避免在默认情况下使用到.so的库, 导致在上线的时候出现麻烦(特别是一些系统中存在,但又与我们需要使用的版本有出入的库).

为了能够控制动态库和静态库的编译, 有下面的几种方式

直接使用要编译的库

在前面也提到了在编译静态库的时候有三种方式

1. 目标文件.o 直接使用
2. 静态库文件.a 直接编译
3. 采用 -L -l方式进行编译

编译的时候如果不采用-Lpath -lxx的方式进行编译, 而且直接写上 path/libx.a 或者 path/libx.so 进行编译,那么在链接的时候就是使用我们指定的 .a 或者 .so进行编译不会出现 所谓的动态库优先还是静态库优先的问题. 但这个方案需要知道编译库的路径，一些情况下并不适合使用。

--static参数

在gcc的编译的时候加上--static参数, 这样在编译的时候就会优先选择静态库进行编译,而不是按照默认的情况选择动态库进行编译.

不过使用--static参数会带来另外的问题,不推荐使用,主要会带来下面的问题

1. 如果只有动态库,而不存在同名的静态库,链接的时候也不会报错,但在运行的时候可能会出现错误 /lib/ld64.so.1: bad ELF interpreter:
2. 由于我们程序本身在运行的需要系统中一些库的支持，包括libc, libm, phtread等库，在采用--static编译方式之后，链接的就是这些库的静态编译版本(glibc还是提供了静态编译的版本)，我们等于使用的是编 译机上的库，但是我们的运行环境可能和编译机有所不同，glibc这些动态库的存在本身的目的就是为了能让在一台机器上编译好的库能够比较方便的移到另外 的机器上，程序本身只需要关注接口，至于从接口到底层的部分由每台机器上的.so来处理．不过这个问题也不是那么绝对，在一些特殊情况下（比如 glibc, gcc存在大版本差异的时候，主要是gcc2到gcc3有些地方没有做好,abi不兼容的问题比较突出,真遇到这些情况其实需要换编译器了)　 --static编译反倒可以正常的运行．但是还是不推荐使用, 这些是可以采用其它方法规范在后面的第6点中有说明．另外就是glibc --static编译可能会产生下面的warning:

warning: Using 'getservbyport_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

这个主要原因是由于getservbyport_r　这样的接口还是需要动态库的支持才可以运行，许多glibc的函数都存在这样的问题, 特别是网络编程的接口中是很常见的．

1. 对一些第三方工具不友好，类似valgrind检查内存泄露为了不在一些特殊的情况下误报（最典型的就是strlen可以参考valgrind的 wikiValgrind运行的程序不能够使用-static来进行链接中的case3), 它需要用动态库的方式替换glibc中的函数，如果静态编译那么valgrind就无法替换这些函数，产生误报甚至无法报错． tcmalloc在这种情况下也不能支持.
2. 我们目前64位环境中使用的pthread库，如果是使用的是动态库那么采用的是ntpl库，如果是静态库采用的linuxthread库，使用--static 会导致性能下降（可以参考