为什么Unix / Linux系统不遍历目录,直到找到所需的链接库版本?


17

我有一个名为“ alpha”的二进制可执行文件,它需要一个链接库(libz.so.1.2.7),该库位于 /home/username/myproduct/lib/libz.so.1.2.7

我通过执行以下命令在生成二进制可执行文件之前将其导出到终端实例。

export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH

现在,当我生成另一个需要相同库但版本不同的应用程序“ bravo”时,即(libz.so.1.2.8)(可在中使用) /lib/x86_64-linux-gnu/libz.so.1.2.8,系统抛出以下错误。

version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)

如果我未设置LD_LIBRARY_PATH,则“ bravo”启动正常。我了解上述行为是因为LD_LIBRARY_PATH/etc/ld.so.conf查找链接库时优先于在其中定义的目录路径,因此发生了上述错误。我只是很好奇一个为什么UNIX / LINUX的开发人员没有设计OS以便如果库的第一个实例是不同版本的情况下就根据层次结构在其他目录中搜索链接的库。

简而言之,UNIX / LINUX系统遍历一组目录,直到找到所需的库为止。但是,为什么在找到期望的版本而不是接受库的第一个实例而不考虑其版本之前,它不做同样的事情?


我不太确定,但我会考虑安全性。我个人不希望担心计算机上任何位置的符号链接
Joe

@Joe许多库本身都有指向它们的符号链接。libz.so.1是指向libz.so.1.2.8
Nasir Riley

Answers:


28

但是,为什么在找到期望的版本而不是接受库的第一个实例而不考虑其版本之前,它不做同样的事情?

据它所知确实如此。zlib.so.1.2.7并且zlib.so.1.2.8两者的名字都zlib.so.1如此,因此your alphabravobinaries表示他们需要zlib.so.1。动态加载程序将加载它找到的第一个匹配库。它不知道版本1.2.8提供了所需的其他符号bravo。(这就是为什么发行版会费力地指定其他依赖项信息的原因,例如zlib1g (>= 1.2.8)for bravo。)

您可能会认为这应该很容易解决,但事实并非如此,尤其是因为二进制文件和库将所需的符号与所需的库分开列出,因此加载程序无法检查给定的库是否提供了所有需要的符号。需要它。可以通过多种方式提供符号,并在符号和库之间引入链接,前提是它们可能会破坏现有的二进制文件。符号插入还增加了使事情复杂化的乐趣(并使对安全敏感的开发人员不知所措)。

有些库提供的版本信息最终存储在中.gnu.version_r,并带有提供库的链接,这在这里会有所帮助,但libz不是其中之一。

(鉴于这些名称,我希望您的alpha二进制文件可以与正常工作zlib.so.1.2.8。)


还要注意的是,GNU风格的库版本不同于我们最习惯的语义(-ish)版本。由于它们具有相同的“当前”编号,因此zlib.so.1.2.8不应该提供zlib.so.1.2.7不具备的任何功能,因此(从ABI角度来看)哪个是无关紧要的?找到了。重要的应该被认为是缺陷。
John Bollinger

4
@John不,唯一的保证是具有相同soname的库是向后兼容的;较新的库可以添加功能,它们不能以向后不兼容的方式删除或更改任何功能。也就是说,针对zlib 1.2.7构建的二进制文件将与该zlib或任何更新的zlib 1一起使用;但是针对zlib 1.2.8构建的二进制文件不一定适用于较早的zlib1。(并且语义版本允许;但soname处理不是语义版本。)
Stephen Kitt,

1
正如我所说的,我专门谈论GNU约定,尤其是关于libtool的猜测。并非每个项目都遵循该约定,因此称zlib有缺陷可能太强大了,但另一方面,即使是所涉及库版本号的语义版本解释也可以得出相同的结论。在这种情况下,向前(二进制)兼容性不是soname固有的承诺,但在这种情况下,这合理的期望。
John Bollinger

1
是的,我很了解CRA编号与SOVERSION之间的关系,这又回到了我的初衷:OP所描述的情况似乎与CRA方案的正确使用不一致。避免诸如OP之类的问题是该方案的主要目标之一。如果zlib添加了新的(版本)二进制接口,则应增加其C号。次要的是,这样的隆起也可能导致反转隆起。
John Bollinger

2
@约翰,对,我怀疑我们在暴力方面达成一致,并且我误解了您的意思。zlib不会使用libtool,除非在达尔文(-)上ar
斯蒂芬·基特
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.