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）バインディングツール管理者がこの問題を解決するのを待つのが正しい方法ですか、それとも直接解決しようとしていますか？ （2）何が起こりましたか？バインディングツールにはlibidn2.so.4が必要ですが、インストールしませんか？メンテナンス担当者はどのようにして間違いを犯すことができますか？
ベストアンサー1
私は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がそれへのシンボリックリンクである場合は、より具体的なファイルにシンボリックリンクする方が合理的です。どのような方法が必ずしも最善かどうかはわかりません。
別のオプションは、libidn2をこの問題以前のバージョンにダウングレードすることです。
どのようにこれが起こったのかについては、libidn2のArch Linux管理者が間違いを犯したようです。私を混乱させるのは、これが起こったということではなく、そのバグが12日前に追加されたということです。いくつかの手動シンボリックリンクで修正できるバグは、修正に数週間ではなく数時間かかります。私はArch Linux管理者を責めるつもりはありません。ちょうどArch Linuxの管理者を責めることです。私は彼らに何が起こったのかわかりません。ただ…苦しいです。私の推測は、これが物語の氷山の一部にすぎないということです。とにかく人は人であり、私たちはみんな間違いを犯します。誰かがすでにこれについて自責しているかもしれませんが、彼らはそうするために私たちの助けを必要としません。