一部のライブラリのワークパッケージ内の一部のファイルに対して、ldd出力が「見つかりません」を返すのはなぜですか？

単純でおそらく明らかな答えは、見ているライブラリの検索パスにlddライブラリ自体の依存関係があるディレクトリが含まれていないことです。通常、ライブラリーの依存関係がシステム全体の標準位置で見つからない限り、指定された実行パス（環境変数$LD_RUN_PATHまたは適切なリンカーオプションを使用）を使用してライブラリーを構築する必要があります。それ以外の場合は、NETと同様に、後で実行時にこれらのライブラリを見つけることができませんldd。

では、なぜThunderbirdはこれらの「問題」にもかかわらずまだ機能しますか？

実行パスが不足しているにもかかわらず、必要なライブラリを見つける方法はいくつかあります。

• 環境変数は$LD_LIBRARY_PATH実行時に設定され、検索する追加のディレクトリのリストを提供します。
• 必要なディレクトリは、現在ライブラリの前にロードされている他の関連ライブラリの実行パスにあり、検索パスにすでに含まれている可能性があります。ちなみに、これが標準に規定されている実装思考であるかどうかはわかりません。それにもかかわらず、ライブラリがロードされる正確な順序に大きく依存するため、脆弱です。
• dlopen()ライブラリは、フルパス名の関数を使用してアプリケーションによって手動でロードされた可能性があります。

Thunderbirdはこの最後の技術を使用しているようです。起動時に出力を見たstrace結果、次のようになります。

• 独自のバイナリがあるディレクトリを探します。 Thunderbirdを起動するシェルスクリプトヘルパーはこれを行うためにフルパス名を使用するため、これは常に可能です。
• dependentlibs.listこのディレクトリにあるテキストファイルを開きます。
• このテキストファイルの各ファイル名のフルパス名を設定するために、同じディレクトリを先頭に追加しますdlopen()。
• 今述べたすべての依存ライブラリlibldap60.soは「事前ロード」されており、それを必要とする他のライブラリはそのライブラリを再検索する必要はありません。

に記載されている順序やファイルがdependentlibs.list重要であることに注意してください。

Thunderbirdがこれを行う理由は、そのディレクトリをアプリケーションまたは内部ライブラリの実行パスにハードコードする必要がないためです。

Javaが何をしているのかわかりませんが、似たようなものがあることは間違いありません。