コンピューティング · 実用ガイド
Linux の「cannot open shared object file」：ライブラリを変える前にローダーの探索を証明する
指定された .so は欠落、実行サービスから不可視、キャッシュ差、または ABI 不一致かもしれません。ldconfig、LD_LIBRARY_PATH、コピー、symlink の前にローダー台帳を作ります。
「Error while loading shared libraries」は実行時ローダーが依存関係を満たせなかったことを示すだけで、似た名前のファイルがない証明ではありません。実行ファイル、ELF interpreter、DT_NEEDED、RUNPATH/RPATH、環境、cache、既定ディレクトリ、architecture、service/container namespace が結果を決めます。
修復は所有者の判断です。配布または vendor package が依存を所有するなら一致する package を修復し、自分の build が所有するなら SONAME と配置を直します。互換性を証明せず global path や major version symlink を作りません。
1. 実際の executable と要求名を記録する
正確な command、path、user、service/container、working directory、error を記録し、wrapper と symlink を解決して execve に渡る ELF を readelf で調べます。
readelf -dW で DT_NEEDED と RPATH/RUNPATH、readelf -lW または file で interpreter と platform を記録します。
2. ローダー探索を再構成する
同じ実行 context から interpreter --list または適切な LD_DEBUG=libs を使い、探索 directory と最初の候補・拒否を記録します。
embedded path、実際の LD_LIBRARY_PATH、cache、default を比較します。systemd、container、sudo、set-user-ID は別環境になり得ます。
3. 候補と所有者を検証する
各候補の ELF header と dynamic section を調べ、class、machine、endianness、SONAME、symbol version を一致させます。symlink は ABI を互換にしません。
package database、vendor manifest、build artifact から所有者を特定し、upgrade での削除、stale cache、不完全 image、wrong architecture、missing runtime を分けます。
4. 狭く修復して clean start を証明する
所有 component の再インストールまたは rebuild と正しい配置を優先します。custom app は意図した RUNPATH または正式設定を使います。
一時 override を外して元の service/container から再試験し、解決 object、起動、architecture、package version と実機能を確認します。
