2010年十二月月 发布的文章

也谈共享库

近两天一直在考量产品安装包改进的事宜。说实话,我们的安装包做得不够"专业",不仅没有按照各个平台的标准安装包形式(比如redhat的rpm,debian的deb或solaris上的pkg包)制作,而且安装包在生产环境中还需要再进行一次链接才能得到最终的可执行程序。这样一来,每次制作安装包都很费时费力(虽然有自动打包脚本),安装包的"体积"也很是庞大,因为包中要包含所有.o目标文件和一部分自有库以及第三方库的.a文件。

究竟为何还需要在生产环境中重新链接一次,此问题年头已久,之前无人深究,现在也就没有了现成的答案,这次花了些时间查了一下,发现居然是有关共享库的一个问题。关于共享库,我平时接触的不多,工作中更多愿意使用静态库进行静态链接,这样一来实际上我对共享库的了解也不够深刻。

众所周知,静态链接和动态链接各有不足,也各有千秋:
采用静态链接,最终可执行文件的Size会比较大,因为你在可执行文件中包含了一份程序所依赖的库中的符号的代码copy(注意:不是整个静态库的copy)。不过也恰是由于这点,可执行程序被部署到运行环境下后就简单多了,它运行时不需要再依赖任何其他库了,是典型的自我满足型。

而动态链接则与静态链接恰恰相反,由于编译时仅仅是记录了其运行所依赖的共享库的名字而并未真正包含一份库的copy,所以这样的可执行文件的Size都较小,但在运行环境中我们需要先进行一番配置以让链接器能找到可执行程序所依赖的共享库。

但实际工作中,完全的采用静态链接有时是会遇到麻烦的。因为很多OS在默认安装时是不带开发包的,也就是说像libc、libpthread等系统库只提供了共享库版本(如/lib下提供了libc的共享库libc.so.6),其静态库版本是需要自行下载、编译和安装的(如libc的静态库libc.a在安装后是放在/usr/lib下面的)。所以多数情况下,我们是将两种链接方式混合在一起使用的,至少像libc这样的系统库多是采用动态链接的。

共享库的制作方法很简单,用下面两行代码我们就可以得到一个名为libfoo.so的共享库:
gcc -fPIC -c libfoo.c -o libfoo.o
gcc -shared -o libfoo.so libfoo.o

不过不知道大家是否留意过:在/lib和/usr/lib等集中放置共享库的目录下,你总是会看到诸如下面的情况:
2010-12-10 12:28 libfoo.so -> libfoo.so.0.0.0*
2010-12-10 12:28 libfoo.so.0 -> libfoo.so.0.0.0*
2010-12-10 12:28 libfoo.so.0.0.0*

关于libfoo.so居然有三个文件入口,其中libfoo.so.0.0.0是真正的共享库文件,而其他两个文件入口则是指向libfoo.so.0.0.0的符号链接。为何会出现这个情况呢?这与共享库的命名惯例和版本管理不无关系。

共享库的惯例中每个共享库都有多个名字属性,包括real name、soname和linker name:
real name – 指的是实际包含共享库代码的那个文件的名字(如上面例子中的libfoo.so.0.0.0),也是在共享库编译命令行中-o后面的那个参数;

soname – 是shared object name的缩写,也是这三个名字中最重要的一个,无论是在编译阶段还是在运行阶段,系统链接器都是通过共享库的soname(如上面例子中的libfoo.so.0)来唯一识别共享库的。即使real name相同但soname不同,也会被链接器认为是两个不同的库。共享库的soname可在编译期间通过传给链接器的参数来指定,如上例中我们可以通过"gcc -shared -Wl,-soname -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o"来指定libfoo.so.0.0.0的soname为libfoo.so.0(在solaris上的命令为"gcc -shared -Wl,-h -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o")。ldconfig -n directory_with_shared_libraries命令会根据共享库的soname自动生成一个名为soname的符号链接指向real name文件,当然你也可以通过ln命令自己来创建这个符号链接。另外在linux下我们可通过readelf -d查看共享库的soname(在solaris下可使用dump -Lvp查看),ldd输出的ELF文件依赖的共享库列表中显示的也是共享库的soname及所在路径。

linker name – 是编译阶段提供给编译器的名字(如上面例子中的libfoo.so)。如果你构建的共享库的real name是类似于上例中libfoo.so.0.0.0那样的带有版本号,那么你在编译器命令中直接使用-L path -lfoo是无法让链接器找到对应的共享库文件的,除非你为libfoo.so.0.0.0提供了一个linker name(如libfoo.so,一个指向libfoo.so.0.0.0的符号链接)。linker name一般在共享库安装时手工创建。

了解了共享库的名称惯例后,我们考虑如何使用这些共享库。使用共享库分为两个阶段,第一个阶段是可执行文件构建阶段。构建阶段我们需要为编译器(实为链接器)提供可执行程序依赖的共享库的位置信息:

如果依赖的共享库放置在链接器搜索的默认目录下(linux下一般依次为/lib和/usr/lib; solaris下依次为/usr/ccs/lib,/lib和/usr/lib),你可以直接使用-l指定共享库的linker name即可;

如果依赖的共享库在非默认路径下,可使用-L来告知位置,比如gcc -o fooapp fooapp.c -L private_shared_lib_dir -lfoo,与默认目录相比,-L指定的目录优先级更高,另外注意:这里-L的位置信息并不记录在fooapp文件中,也不会对fooapp的执行产生影响;

在Solaris上,通过配置LD_LIBRARY_PATH也可以为编译器指定共享库路径,且其优先级比-L指定的路径更高,不过在Linux上LD_LIBRARY_PATH在编译阶段似乎不起作用。

运行时阶段,链接器同样要确定可执行文件依赖的共享库的位置和版本,不过与编译构造阶段不同,运行时的链接器按如下顺序搜索共享库:

-rpath
链接器优先在可执行文件中记录的rpath路径下搜索。rpath是在编译时传给链接器的路径参数:
linux平台下可使用:gcc -o fooapp fooapp.c -Wl,-rpath -Wl,fooapp_rpath -L foo_so_path -lfoo
solaris下可用:gcc -o fooapp fooapp.c -R fooapp_rpath -L foo_so_path -lfoo
多个路径可用冒号分割。编译成功后,这些信息会被记录在最终文件的RPATH节中,在运行时链接器读取RPATH节并搜索其值对应的目录。ldd 显示的是运行时应用依赖的库及其在运行环境下的确定路径,例如ldd fooapp的结果为:libfoo.so.0 => fooapp_rpath/libfoo.so.0 (0×00458000)

LD_LIBRARY_PATH
如果fooapp_rpath实际并不存在,则链接器会尝试在LD_LIBRARY_PATH配置的路径中查找依赖的共享库。

ldconfig配置的缓存中的路径
如果在rpath和LD_LIBRARY_PATH中依旧没有搜索到libfoo.so,那么链接器将尝试在ldconfig配置缓存中查找。linux平台上使用ldconfig配置搜索路径的方法如下:在/etc/ld.so.conf.d下增加一个自定义的链接器搜索路径配置文件,执行ldconfig更新缓存后生效。

系统默认路径
链接器最后将在默认路径下查找相关共享库,linux和solaris下均为/lib和/usr/lib。

如果在以上路径下依然没有找到libfoo.so,那么fooapp运行将出错。

好了,到目前为止,前面提到安装包的问题的原因也可以解释清楚了,问题就在于使用了-rpath但却没有在生产环境下进行共享库的配置。一旦安装包制作环境下记录到-rpath中的路径在生产环境下无法找到,且生产环境下没有将相关库的路径配置到链接器搜索的路径下,那么安装后的可执行文件执行时就会出错。解决方法有多种,这里就不赘述了。

别为代码的"Bad Smell"提供土壤

上周初参加了一次代码评审,评审时发现一位同事在自己负责的子模块代码里定义了一个私用宏,"重复"这个Bad Smell立马在我头脑中闪现。当时我给出了一个建议:检查一下这个宏定义的必要性,依次检查一下C运行库头文件中是否已经有了同功用宏定义,基础库头文件中是否已经有了同功用宏定义,业务层代码的共用头文件中是否已经有了同功用宏定义。

周末这位同事给出了答复:C运行库、基础库和业务层代码中都没有定义此功用的宏。考虑一下这位同事如此编码的动机:显然一方面他为了避免magic number才去定义一些宏,提高可读性。另一方面确实无此功用的宏可用才考虑定义在自己的子模块中。但是这个宏的定义到底该放在哪里才是正确的呢?

这个宏是作为一个buffer的size而定义的,这个buffer会作为基础库中某个函数的输出参数,而这个函数原型声明所在的头文件中却没有提供相关宏为上层开发者所使用,这才导致了调用者自己猜测并设置buffer size。不讲究的开发者很可能就直接使用一个magic number,而像我这位同事采用的这种方法又会导致一些"重复"的Bad Smell的出现。这样来看,也许正是这个库函数的设计者为Bad Smell提供了滋生的土壤。

库设计者应该多为上层调用者考虑,这方面可参考一些优秀库的设计,如C标准库等。因为你的接口设计而给调用者带去Bad Smell,这是我们不希望看到的。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats