标签 Solaris 下的文章

"%05s"行为未定义

下班前,一位同事发来的mail中提到这样一个问题:在Solaris上,新添加到Project中的一段代码编译有Warning,由于我们在Makefile的GCC命令行中设置了"视警告如错误"的-Werror编译选项,导致了项目无法成功Build。

这个Warning内容如下:
warning: `0' flag used with `%s' printf format

产生这个Warning的那行代码大致是类似这样的:printf("%05s%06s\n", "11", "222"); 其实这段代码是从老项目中Copy出来的,在老项目中,这段代码运行的很是正常,也许它在老项目Build时也会产生Warning,不过之前大家也都没有关注。

这个Warning我以前还真未遇到过,代码看起来写的也没有问题,我在Ubuntu 10.04(GCC 4.4.3)上测试了一下这段代码,同样产生了Warning。不过执行一下编译后的程序,我发现了问题。显然这段代码的意图是想通过"%05s"这样的格式控制串来达到自动补0的目的,但是Ubuntu下输出的结果却与此预期相悖–没有补0,补的是空格。我又拿同样的代码在Solaris(Solaris 10 for x86, gcc 3.4.6)上试了一下,虽然也有Warning,但结果和预期是相符的。

这个问题显然比我预期的严重:一段代码在两个平台上产生了不同的行为,问题显然出在"%05s"的使用上。翻开《C语言参考手册》找到输入/输出函数一章,在"输出转换说明"一表中可与s转换搭配的只有'-标志',没有'0标志',但手册里并未明确说明如果将0标志与s转换结合会有什么后果。又Google了一下,发现一些资料里提到在printf系列接口中使用类似"%5s"这样的格式控制串的行为是未定义的,和我试验的结果一致。

考虑到可移植性,"%05s"这样的格式控制串不能再继续使用了,替代方法有多种,这里就不赘述了。如果你的代码里也有使用类似"%05s"这种格式控制串,那赶紧想办法替换掉吧,除非你的代码一直跑在Solaris上。

也谈共享库

近两天一直在考量产品安装包改进的事宜。说实话,我们的安装包做得不够"专业",不仅没有按照各个平台的标准安装包形式(比如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中的路径在生产环境下无法找到,且生产环境下没有将相关库的路径配置到链接器搜索的路径下,那么安装后的可执行文件执行时就会出错。解决方法有多种,这里就不赘述了。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位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