Is there any common reason not provide such symbolic links? Which goal is achieved by that?
唯一值得关注的原因是库的符号链接版本和已安装的库之间是否存在库 API 更改。在这种情况下,如果找不到所需的函数名称,您将收到链接器错误,或者如果所有名称都相同,但给定函数的操作在版本之间发生了变化,您将收到损坏的代码。当您手动创建到共享库的符号链接时,您有责任确保您需要的库调用在共享库版本之间是相同的。通常,当一个库更改其soname
(共享对象名称)时,它会这样做,因为该库的用户需要了解并确认正确使用该库中的一些潜在更改。libz.so
您需要和您的系统具有的事实libz.so.1
表示发生了此类更改或soname 颠簸。您需要确认您需要的功能libz.so
在libz.so.1
. (大多数时候库是向后兼容的,但有时它们不是[例如 libpng-1.2 和 libpng-1.4])
这就是 sonames 的全部意义所在。当您发现自己处于需要手动创建符号链接或降级 libz 以获得所需libz.so
的情况时——soname 更改告诉您libz.so 和 libz.so.1 之间存在库更改,所以它由您决定是否可以按照您尝试的方式使用libz.so.1
符号链接。libz.so
为什么你甚至需要符号链接?为什么你的代码不应该因为没有符号链接而感到高兴libz.so.1
呢?libz.so
您正在编译的代码正在寻找libz.so
. 如您所见,它不存在于您的系统中。通过提供libz.so -> libz.so.1
符号链接,您可以让您的代码在不修改代码的情况下libz.so.1
通过名称查找。libz.so
创建符号链接基本上只是解决修复代码以使用libz.so.1
. 根据您对任一系统上代码的访问权限,这可能是必要的,但处理这种情况的正确方法是更新两个系统和代码以使用/使用当前库构建libz.so.1
话虽如此,如果更改libz.so.1
不会影响libz.so
您需要使用的任何部分,那么符号链接就可以正常工作。