如何处理非工作包中的共享库问题

Question

我安装了 bind-tools，Arch linux 的 dnsutils 替代品，但没有一个工具可以工作，全部失败并出现错误：

host: error while loading shared libraries: libidn2.so.4: cannot open shared object files: No such file or directory

libidn2.so.4 的这个问题似乎是 Arch 软件包构建的最新问题（2019 年 1 月），并且显然产生了一些非常可怕的结果，例如使整个系统无法启动。

我的问题是：（1）是等待bind-tools的维护者修复这个问题，还是尝试自己修复它，这是正确的方法吗？(2)到底发生了什么？bind-tools 需要 libidn2.so.4 但不安装它？维护人员怎么可能犯这样的错误呢？

Answer 1

我不运行 Arch Linux，所以我在这方面有点冒险。

您链接到的文章表明它缺少符号链接，而不是缺少包。这是有道理的，因为通常在 Linux 中，共享库在“.so”之后至少有两个八位字节的版本号，而错误只提到了一个。

我的建议是你跑

ls -l /usr/lib/libidn2.so*

看看它返回什么。如果只是返回的话

/usr/lib/libidn2.so

并且没有提到任何更具体的内容，那么我建议运行

ln -s /usr/lib/libidn2.so /usr/lib/libidn2.so.0
ln -s /usr/lib/libidn2.so /usr/lib/libidn2.so.4

我建议同时运行两者，因为您的程序似乎正在寻找该库的主要版本四，但您引用的文章正在寻找主要版本零。此修复基本上为文件 /usr/lib/libidn2.so 创建了两个别名，一个带有 .0，另一个带有 .4。

如果您看到有一个 /usr/lib/libidn2.so.something.something，并且 /usr/lib/libidn2.so 是它的符号链接，那么符号链接到更具体的文件可能更有意义。我真的不知道哪种方式一定是最好的。

您的另一种选择是将您的 libidn2 降级到出现此问题之前的版本。

至于这是如何发生的——看起来 Arch Linux 的 libidn2 维护者犯了一个错误。让我困惑的不是这件事发生了，而是……那个 bug 是 12 天前添加的。可以通过一些手动符号链接修复的错误应该需要几个小时而不是几周的时间才能修复。我并不是有意贬低 Arch Linux 维护者；我只是想贬低 Arch Linux 的维护者。我不知道他们这边发生了什么。这只是……令人沮丧。我的猜测是，这只是这个故事的冰山一角。无论如何，人就是人，我们都会犯错。有人可能已经为此自责，他们不需要我们的帮助来做到这一点。