問題タブ [ldd]

Qt実行可能ファイルがあります。このプログラムをUbuntu11.04仮想マシンで実行すると、GUIは見苦しくなりますが、それでも必要なGUIであることがわかります。ただし、私のラップトップのUbuntu 12.04で実行すると、すべてがうまくいきます。したがって、仮想マシンの環境に問題があるのではないかと思います。

問題がライブラリにあるかどうかを確認するために、コマンドを実行しました

私は次のようにライブラリの依存関係を取得しました：

それでは、どうして違うのだろうか。straceなどのツールで何が問題になっているのかを知ることはできますか？

複数のディレクトリの下で非標準の命名規則を使用して共有ライブラリをリンクすることに関して問題があります。実行可能ファイルの現在の場所で共有ライブラリを検索するには、生成された実行可能ファイルが必要ですが、この動作を強制するコマンド ライン パラメーターが見つかりません。

この動作を実証するために必要なのは、ディレクトリの下にある共有ライブラリだけです。

実行可能な mainは、次の ldd 出力を提供します。

私が必要とする出力は次のとおりです。

この出力は、ライブラリの名前が慣例に従ってmylib.soではなくlibmylib.soである場合に作成できます。

これにより、必要に応じて ldd リストのパスsome/dirも削除されます。

rpath の使用、および ld と gcc の両方のコマンド ライン オプションを調査しましたが、満足のいく解決策を見つけることができません。この場合、非標準の名前とディレクトリ構造の厳格な要件を簡単に変更することはできません。

私の質問は、ライブラリの依存関係を、gcc コマンド ライン オプションを介して 2 番目の ldd のように絶対ではなく、現在のディレクトリに対して強制的に相対的にする方法です。

お時間をいただきありがとうございます。問題を合理的に説明できたことを願っています。

ジョン。

次のように、ldd を使用して依存関係を判別できます。

"date" は "libc.so" に依存するため、"date" は "libc.so" 内の何らかの関数を呼び出すと想定し、ldd は実行可能ファイルの .dynamic セクションから "date" の lib 依存関係を判断できることを知っていますが、問題は、コンパイラ/リンカーが .dynamic セクションに何を書き込む必要があるかをどのように認識するかです。もう少し詳しく言うと：

1. "libc.so" が "date" に静的にリンクされている場合、この関数のコードは既に "date" にコンパイルされているはずです。したがって、この場合、"date" は "libc.so" に依存してはならず、 .dynamic セクションの「libc.so」。

2. 「libc.so」が「date」と動的にリンクされている場合、この場合、次のようなコードを想定しています。

ハンドル = dlopen("libc.so", ..);

"libc.so" をロードするには "date" に存在する必要があり、"dlopen("libc.so")" は、"date" が "libc.so" に依存しているという唯一の手がかりになるはずです。リンカーは、「日付」が「libc.so」に依存していることを知っていますか? lib依存関係を抽出するためにすべての「dlopen」行を解析しますか? これは良い方法だとは思いませんが、これは本当でしょうか?

または、コンパイラ/リンカーには、動的リンクの場合にライブラリの依存関係を判断する他の方法がありますか? ありがとう。

ldd が予期しない依存関係と libicuuc (「icu」から) を示すバイナリがあります。

このシステムでは、libxml は libicuuc に動的に依存しているため、ldd が最終的に libicuuc を見つけてしまうのは理にかなっていますが、libicuuc も A の ldd 出力に表示されると予想されますか? 依存関係の依存関係としてリンクされているライブラリのみを取得するコマンドはありますか?

一部のデバイスにロードされないlibTest.soがあります。logcatは絶対に役に立たない。を使用しarm-linux-androideabi-readelf.exe -d libTest.soて、libTest.soが必要とするすべての必要なライブラリを確認することができました。それらをすべてローカルPCの同じフォルダーに取り込みました。

どのシンボルがどのライブラリにないかを確認するにはどうすればよいですか？NDKの標準的なツールセット（nm、readelf、objdumpなど）しかありません。どのツールとどのように使用すれば、libTest.soとすべての依存ライブラリも解析され、どのシンボルがターゲットデバイスへのライブラリのロードを妨げているかがわかります。

Fedora 18 では、次のようなファイル「ac」を作成しました。

そして、gcc 4.7.2 でコンパイルしました:gcc a.c -o a
最後に ldd 2.16 を使用しました:ldd -u ./a
出力はとても奇妙です:

Unused direct dependencies:
/lib64/libc.so.6

私はオブジェクトファイルが実際に使用していると思い/lib64/libc.so.6ますprintf(). そして、Red Hat 6 では、
この奇妙な外観はありません。

Linux では、dlopen() を使用していくつかの共有ライブラリをロードする C++ アプリケーションがありますが、デバッグ トレース コードが正常に動作していないように見えるため、ロードされている共有ライブラリのバージョンが予期したものではないのではないかと疑っています。実行されました。

実行中のプロセスをチェックして、現在開いているすべての共有ライブラリとそれらの各ライブラリへのパスを照会する方法はありますか? 言い換えれば、何かに似てlddいますが、実行中の実行可能ファイルで機能し、ランタイムにロードされたライブラリもリストします。

Linux では、ldd には非常に便利なオプション LD_DEBUG があります。

LD_DEBUG (glibc 2.1 以降) 動的リンカーに関する詳細なデバッグ情報を出力します。all に設定すると、すべてのデバッグ情報が出力されます。help に設定すると、この環境変数で指定できるカテゴリに関するヘルプ メッセージが出力されます。glibc 2.3.4 以降、LD_DEBUG は set-user-ID/set-group-ID バイナリでは無視されます。

FreeBSDでできますか?