web-dev-qa-db-ja.com

機能していないパッケージの共有ライブラリの問題に対処する方法

Dnsutilsに代わるArch Linuxであるbind-toolsをインストールしましたが、どのツールも機能せず、すべてエラーで失敗しました。

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を必要としますが、それをインストールしませんか？メンテナはどのようにしてこのようなエラーを起こす可能性がありますか？

arch-linuxpackage-managementdnsdependencies
3
Tyler Durden

私はArch Linuxを実行していないので、これについて少し考えてみます。

リンクした記事は、パッケージが不足しているのではなく、シンボリックリンクが不足していることを示しています。これは理にかなっています。通常、Linuxでは、共有ライブラリには「.so」の後に少なくとも2オクテットのバージョン番号があり、エラーは1つしか言及していないためです。

私の提案はあなたが走ることです

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

あなたのプログラムはライブラリのメジャーバージョン4を探しているようですが、参照した記事はメジャーバージョン0を探しているので、両方を実行することをお勧めします。この修正により、ファイル/usr/lib/libidn2.soに基本的に2つのエイリアスが作成されます。1つは.0で、もう1つは.4です。

/usr/lib/libidn2.so.something.somethingがあり、/ usr/lib/libidn2.soがそのファイルへのシンボリックリンクであることがわかった場合、より具体的なファイルへのシンボリックリンクを作成する方が理にかなっている可能性があります。どちらの方法が必ずしも最善であるかは本当にわかりません。

もう1つの選択肢は、libidn2をこの問題が発生する前のバージョンにダウングレードすることです。

これがどのように起こるかに関しては、Arch Linuxのlibidn2のメンテナがミスをしたようです。私を困惑させるのは、これがまったく起こらなかったことではありませんが...そのバグは12日前に追加されました。手動のシンボリックリンクで修正できるバグは、修正に数週間ではなく数時間かかるはずです。私はArch Linuxのメンテナーを非難するつもりはありません。彼らの側で何が起こっているのか私にはわかりません。それは...イライラするだけです。これはこの話の氷山の一角にすぎないと私は推測しています。いずれにせよ、人は人であり、私たちはすべて間違いを犯します。おそらく誰かがすでにこれを打ち負かしており、彼らはそれを行うために私たちの助けを必要としません。

2
Ed Grimm

これはArch Linuxで頻繁に発生する種類のエラーなので、パッケージを分析し、それらが正しくビルドされているかどうかを判断するための専用スクリプトを作成しました。 （95％の場合、Arch Linuxパッケージは正しくビルドされています）： https://github.com/eli-schwartz/dotfiles/blob/master/bin/pkg-list-linked-libraries

Bind-toolsパッケージでこれを実行してlibidn2を探すと、bind-toolsの最新バージョンがlibidn.so.4にリンクされていることがわかります。

$ pkg-list-linked-libraries bind-tools libidn2
==> checking linked libraries for bind-tools-9.13.5-4-x86_64.pkg.tar.xz ...
/usr/bin/Dig
  NEEDED               libidn2.so.4
/usr/bin/Host
  NEEDED               libidn2.so.4
/usr/bin/nslookup
  NEEDED               libidn2.so.4

そのライブラリはどこから来たのですか？

$ pacman -Qo /usr/lib/libidn2.so.4
/usr/lib/libidn2.so.4 is owned by libidn2 2.1.0-1

pacman -Si bind-toolsの出力によると、Archのbind-toolsパッケージは、依存関係としてlibidn2パッケージを必要とします。

この記事の執筆時点での公式のArch Linuxリポジトリにある2つのパッケージのバージョンは、上記で確認したbind-toolsとlibidn2のバージョンに対応しています。

$ expac -S '%n %v' libidn2 bind-tools
libidn2 2.1.0-1
bind-tools 9.13.5-4

つまり、最新バージョンのbind-toolsがインストールされていることは明らかです。しかし、バイナリに必要なlibidn2ライブラリがないと主張しています。何故なの？現在インストールされているlibidn2のバージョンは何ですか？ pacman -Q libidn2の出力を確認してください。

パッケージは他の何千人もの人々のために機能するので、私の結論はあなたのシステムが壊れており、最新バージョンのlibidn2をインストールするにはシステムを適切に更新する必要があるということです。これが発生する理由、適切に修正する方法、シンボリックリンクが解決策ではない理由の詳細については、 https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported を参照してください、しかしあなたのシステムをさらに壊すでしょう。

放物線のバグに関しては、それは正反対の問題です。 not Arch Linuxである完全に異なるLinuxディストリビューションは、新しいlibidn2を使用してパッケージを再構築できませんでした。その結果、これらのパッケージは誤ってlibidn2.so.0にリンクしていました

その放物線のバグに本当に苦しんでいる場合は、Arch Linuxをまったく使用しておらず、実際に放物線を使用していることを指定する必要があります。そうしないと、人々があなたを助ける方法を知らないためです。

1
eschwartz