/usr/local/lib 中缺少符号链接

Posted 2023-02-22

【中文标题】/usr/local/lib 中缺少符号链接

【英文标题】：Missing symbolic link in /usr/local/lib

【发布时间】：2014-08-16 08:52:29

【问题描述】：

对于我的嵌入式 linux (TI AM335x) 板，我有一个包含子文件夹 sysroot 和文件系统的 SDK。例如。对于 libz：

sysroot/.../usr/lib 包含：

libz.so         # symbolic link to libz.so.1.2.7
libz.so.1       # symbolic link to libz.so.1.2.7
libz.so.1.2.7

文件系统/usr/lib/包含

libz.so.1       # symbolic link to libz.so.1.2.7
libz.so.1.2.7

文件系统不包含符号链接 libz.so --> libz.so.1.2.7。但我的链接器想要它。所以我添加了它。 我的问题：是否有任何常见的原因不提供此类符号链接？达到了哪个目标？

【参考方案1】：

这样做的原因是链接到库的程序可以只指定一个“soname”，它链接到库的“真实名称”。如果您决定升级库，链接器现在链接到最新版本，而不必总是更改链接器配置。如果您想了解更多信息，请查看here。

【讨论】：

这是为最新版本提供符号链接的原因。但是我问了一个为什么在使用的系统没有提供这样的链接。

【参考方案2】：

 Is there any common reason not provide such symbolic links? Which goal is achieved by that?

唯一担心的原因是库的符号链接版本和已安装的库之间是否存在库 API 更改。在这种情况下，如果找不到所需的函数名称，您将收到链接器错误，或者如果所有名称都相同，但给定函数的操作在版本之间发生了变化，您将收到损坏的代码。当您手动创建指向共享库的符号链接时，您负责确保您需要的库调用在共享对象库版本之间是相同的。通常，当一个库更改其soname（共享对象名称）时，它会这样做，因为该库的用户需要注意库中的一些潜在更改并确认正确使用。您需要libz.so 并且您的系统有libz.so.1 的事实表明发生了这样的更改或soname bump。您需要确认libz.so 提供的功能存在并且在libz.so.1 中保持不变。 （大多数时候库是向后兼容的，但有时它们不是[例如 libpng-1.2 和 libpng-1.4]）

这就是 sonames 的重点。当您发现自己处于需要手动创建符号链接或降级 libz 以获得所需的libz.so 的情况时，soname 更改告诉您 libz.so 和 libz 之间存在库更改.so.1 因此，您可以自行决定是否可以按照您尝试的方式使用符号链接到 libz.so 的 libz.so.1。

为什么你甚至需要符号链接？为什么你的代码不应该只使用libz.so.1 代替libz.so 而没有符号链接？您正在编译的代码正在寻找libz.so。如您所见，它不存在于您的系统中。通过提供libz.so -> libz.so.1 符号链接，您可以让您的代码通过名称libz.so 找到libz.so.1，而无需修改您的代码。创建符号链接基本上只是解决您的代码以使用libz.so.1 的一种解决方法。根据您对任一系统上代码的访问权限，这可能是必要的，但处理这种情况的正确方法是更新两个系统和代码以使用/使用当前库libz.so.1

话虽如此，如果对libz.so.1 的更改不影响您需要使用的libz.so 的任何部分，那么符号链接就可以正常工作。