Linux で共有オブジェクト (ライブラリ) の依存関係を操作する方法

共有ライブラリのロード中のエラー: すべての Linux ユーザーが遅かれ早かれ遭遇する恐ろしいエラーです。実行可能ファイルで使用される共有オブジェクトの依存関係 (ライブラリ) で問題が発生しました。このような問題などを解決する方法を学びましょう。

共有オブジェクトの依存関係とは何ですか?

共有オブジェクト (ライブラリとも呼ばれます) は、Linux インスタンス上の複数のプログラム/アプリケーションによって使用されるバイナリ (通常は直接実行可能ではありません) です。このようなライブラリは、多くの場合、オペレーティングシステムレベルでインストールされ、共有されます (そのため、 共有オブジェクト または

libraries

) 1 つ以上 (さらには多数) の直接実行可能なアプリケーションで使用されます。

たとえば、ファイルの圧縮機能を備えたプログラムでは、そのために bz2 (bzip2) ライブラリ libbz2.so.1.0 が必要になる場合があります。 ライブラリ という用語は Linux 界隈でより頻繁に使用され、専門家の間で好まれる専門用語ですが、 共有オブジェクト (および 共有ライブラリ ) はどちらも技術的には正しいものです。また、多くのライブラリで使用されている .so ファイル名拡張子が 共有オブジェクト を表していることにも注目してください。

実行可能ファイルには、依存するライブラリを 0 つ、1 つ、または多数含めることができます。ライブラリが少ないほど、(オペレーティングシステムをアップグレードする場合などに) 互換性が向上します。ライブラリが増えると、遅かれ早かれ一部のライブラリの依存関係が壊れる可能性が高くなります。これは、アプリケーションベンダーがリリースを決定する場合がある理由でもあります。

 statically compiled binaries

それよりも

dynamically compiled binaries

。

静的にコンパイルされたバイナリと動的にコンパイルされたバイナリの違いは単純ですが、広範囲にわたる影響を及ぼします。静的にコンパイルされたバイナリには、結果として得られるバイナリ/実行可能ファイルにコンパイルされたライブラリ (コンパイル時に開発者システムで利用可能) が含まれています。動的にコンパイルされたバイナリは、ユーザーのシステムにインストールされ、利用可能で、共有されているライブラリを使用します。

すぐにわかるように、オペレーティングシステムまたはアプリケーションベンダーのパッケージ管理システムと詳細で同様の処理が行われていない限り、ユーザーはそのような必要な依存関係をインストールする必要があります。このため、次のような単純なコマンドを実行します。

 sudo apt install .. .some_app ...

多くの場合、他の関連するもの (つまり、必要なライブラリ) のセットが同時にインストールされます。

静的コンパイルと動的コンパイルの両方に長所と短所があります。たとえば、静的コンパイルを使用していて、(ソフトウェアベンダーの観点から) ソフトウェアパッケージに含めたライブラリにセキュリティバグまたは重要なアップデートが存在する場合、再リリースする必要がある可能性があります。コードに何も変更がなかったとしても、ソフトウェアパッケージ。

しかし、繰り返しになりますが、特に複雑なプログラムの場合、またはソフトウェアの自己コンパイルが必要な場合に、エンドユーザーがそのようなことで苦労することが多いことを認識して、ライブラリのインストールをユーザーに依存することも理想的ではありません。これは複雑な分野であり、この問題は頻繁に議論されてきました。

この記事では、オペレーティングシステムのプログラム/実行可能ファイル/ツールの場合によくあることですが、動的にコンパイルされたプログラムに関連する共有ライブラリを見ていきます。静的にコンパイルされたプログラム (あまり一般的ではありません) では、「共有ライブラリのロード中にエラーが発生しました」のようなエラーが表示される可能性はほとんどありません。これは、プログラムが部分的に動的であり、限られた組み込みのセットのみが含まれている場合を除き、ライブラリは実行可能ファイルに含まれるためです。静的ライブラリで。

共有ライブラリのロード中にエラーが発生しました!

しばらく root モードに切り替えてみましょう (使用

sudo su

) のようなツールに関して共有ライブラリがどのように機能するかを調べます。

 /usr/bin/zip

これは、主要な Linux ディストリビューションに含まれているか、インストール可能です。

ここでは、ディレクトリを次のように変更しました。

 /usr/bin

かどうかを確認しました

zip

プログラム/バイナリ/実行可能ファイルが存在します。存在することがわかったので、次にそれを呼び出してバージョンを確認しました。

 --version

そして、出力をパイプすることにより、出力の先頭 2 行のみを取得します (次を使用します)。

) そうしないと長い出力が発生するのを避けるためです。

最後に、 ldd ツール (共有オブジェクトの依存関係を出力するプログラム) を使用して、実行可能ファイルに必要なライブラリを確認しました。見てわかるように、プログラムには 4 つの共有ライブラリが必要です。必要なライブラリのリストは、通常、必要なライブラリの後に、指定されたライブラリが既に見つかったパスが続く形式になっています。

一部のトップレベルまたは特殊な OS レベルのライブラリ (たとえば、

 linux-vdso .so .1

)、そのようなパスは表示されません。ただし、どのエントリにもエラーが表示されない限り、それは問題なく使用可能 (または推奨) であることがわかります。実際には、

 linux-vdso .so .1

Linux カーネルによってすべてのプロセスに挿入される特別な仮想共有オブジェクト/ライブラリです。Linux カーネルには、ディスク上に物理ファイルがありません。システムコールをより効率的にするためにあります。

そこで、少しやり方を変えて、必要なライブラリの 1 つの名前を変更して、バイナリによって自動的に検出されないようにしてみましょう。

ご覧のとおり、ここではファイルの名前を変更/移動しました。

 /lib/x86_64-linux-gnu/libbz2.so.1.0

に

/lib/x86_64-linux-gnu/libbz2.so.1.0.NOT_PRESENT

。これにより zip アプリケーションが壊れ、それを実行しようとすると恐ろしい事態が発生します。

 error while loading shared libraries

エラー。ただし、もう少し詳しく見てみると、エラーメッセージは実際には非常に説明的です。

 zip: 共有ライブラリのロード中にエラーが発生しました: libbz2.so.1.0: 共有オブジェクト ファイルを開けません: そのようなファイルまたはディレクトリはありません

経験豊富な IT エンジニアは、問題について問い合わせる前に、提示されたログやプログラムの出力/情報を常に注意深く確認します。必要なファイル libbz2.so.1.0 が明確に示されており、問題も明確に示されているため、ここでも効果があるでしょう。 No such file or directory 。つまり、 libbz2.so.1.0 がありません。

上の画像でわかるように、 ldd でも同じことを確認できます。 libbz2.so.1.0 => not found 明確なメッセージは、何が起こっているかを知るのに役立ちます。動的にコンパイルされたバイナリ (オペレーティングシステムのほとんどのバイナリはこの方法でコンパイルされます) がどのようにライブラリをロードして必要とするのか、また、ライブラリが欠落しているかどうか (またはエラーメッセージによって通知されるのか) を確認する方法を明確に理解すると、状況は変わります。もうそれほど複雑には見えません。

さらに、必要なライブラリ名がわかったら、お気に入りの検索エンジンで簡単に検索すると、必要なライブラリ名を取得するためにインストール (または再インストール) する追加のパッケージが表示されます。多くの場合、パッケージ名はライブラリ名から直接解釈することもできます。ただし、この場合、ランタイムライブラリの名前は少しずれています。

ライブラリには、ランタイムライブラリと開発ライブラリの 2 種類があります。この場合、 libbz2.so.1.0 ライブラリを含むパッケージ名はおそらく bzip2 であり、アンインストールしようとすると削除されるプログラムの長いリストから一目でわかるように、アンインストールしようとすると他のさまざまな項目が壊れる可能性があります。または、 bzip2 パッケージをパージします。

2 番目のタイプのライブラリは開発ライブラリです。これらは、プログラムをコンパイルしようとするときに必要になることが多く、多くの場合、実際のライブラリファイル名とさらに密接に関連しています。たとえば、Ubuntu では、ライブラリ名を取得して -dev を追加するだけです。たとえば、 libbz2.so.1.0 パッケージに関連する開発パッケージをインストールしたい場合は、 libbz2-dev のインストールを検討します。

この開発ライブラリは libbz2.so.1.0 ランタイムライブラリに直接関連していませんが、Ubuntu のほとんどの開発パッケージ名の命名構文 ( lib のプレフィックスと -dev のサフィックスの間にライブラリ名を挟んだもの) を知っておくと役立ちます。それら）特定の開発ライブラリが必要な場合（ソフトウェアのコンパイル時に最も必要となる場合がほとんどです）。

また、何らかのライブラリが何らかの理由で破損したと仮定します。その場合、最も簡単なクイックフィックスの 1 つは、ライブラリをパージする sudo apt purge your_library_name コマンド (渡されたライブラリ/プログラムを完全にパージします) に続いて、 sudo apt install your_library_name コマンドを使用して再インストールすることです。

また、ランタイムライブラリをアンインストールするにはメインプログラムをアンインストール/パージする必要があり、そのようなパージ/削除がオペレーティングシステムの大部分を占めるか、他の多くのものに影響を与える場合に、上記と同様の状況に遭遇した場合は、代わりに再インストールオプションを使用できます。

 sudo apt 再インストール bzip2

ただし、常にこれほど簡単なわけではありませんが、上記のこと (特に -dev の追加に関する命名規則) を知っていれば、問題のトラブルシューティングに非常に役立ち、多くの場合、問題を直接解決できます。

また、 ldd を使用してライブラリをチェックする方法を知ることも非常に役立ちます。そして最後に、ライブラリは /lib のサブディレクトリまたは /usr/lib などに存在する単なる実行可能 (直接ではありませんが) .so ファイルであることを理解することにも役立ちます。同様のディレクトリ。

場合によっては、ライブラリやパッケージが互いに競合したり、特定のパッケージが特定のライブラリバージョンを必要としたり、特定のライブラリが特定のバージョンの他のライブラリを必要としたりすることがあります。はい、少し複雑になります。また、これほど複雑になると、システムを少し混乱させることも簡単になります。場合によっては、重要すぎるライブラリの移動などにより、オペレーティングシステムのインストールが完全に中断される可能性さえあります。

多くの場合、古いバージョンで不足しているライブラリに対してシンボリックリンク (別の既存のファイルまたは別のシンボリックリンク自体を参照/リンクし、実際のファイルを指す、指定されたファイル名を持つ仮想リンク) を作成する方がいくらか安全です。、そしてそのシンボリックリンクを最新のインストールされたバージョンにポイントします。常に機能するとは限りませんが、失敗した場合に備えて、シンボリックリンクを削除でき、できれば安全です (同じ名前のシンボリックリンクやファイルが事前に存在しないことを前提としています)。

これらのより複雑な問題をトラブルシューティングする最善の方法は、常に最初に apt (またはオペレーティングシステム上の同様のパッケージ管理ツール) ベースのソリューションを試すことです。この時点で、パッケージをより詳細に管理する方法が示されているので、dkpg を使用して apt を修正する方法も読んでください (ただし、より多くの制御にはより多くの責任が伴うため注意してください)。

他のすべてが失敗した場合は、シンボリックリンクを作成するか、ライブラリファイルを手動で追加してみてください。 (ダウンロードしたファイルにウイルスが含まれていないことを、たとえば VirusTotal でチェックするなどして、三重に確認してください。また、バイナリをダウンロードするには、Linux ベンダーが提供するリポジトリを使用することが常に最善です。)

極端な場合には、近隣の Linux オペレーティングシステムでライブラリを見つけることもできるかもしれません。たとえば、Ubuntu 実行可能ファイルは Mint 上で実行され、その逆も同様です。所有している別の PC からライブラリをコピーすることも、場合によっては有効な方法です。

まとめ

きめ細かいライブラリ管理は、一生かけて習得するスキルです。それはほとんど芸術です。この記事では、基本的な情報/ノウハウと使用するツールを提供し、状況が不透明になった場合に備えたより高度なトラブルシューティングの提案をいくつかリストしました。定期的にパッケージをインストールする Linux の頻繁なユーザーであれば、遅かれ早かれそれらが役立つでしょう。

次に Linux マシンで「共有ライブラリのロード中にエラーが発生しました」というエラーが表示された場合は、この記事で説明されているように、 ldd などのツールを使用すると、問題の原因がどこにあるのかをよりよく理解できるようになります。また、静的コンパイルされたバイナリと動的にコンパイルされたバイナリと、共有ライブラリまたは組み込みライブラリがどのように両方に適合し、動作するかについても検討しました。

この記事を気に入っていただけた場合は、上にリンクされている dpkg に関する記事や、「 Ubuntu でユニバース、マルチバース、制限付きリポジトリを追加する方法」もお読みください。