問題タブ [dynamic-linking]

特定の状況で動的リンクよりも静的リンクを選択したり、その逆を選択したりする魅力的なパフォーマンス上の理由はありますか? 私は次のことを聞いたり読んだりしましたが、その真実性を保証するのに十分な知識がありません.

1) 静的リンクと動的リンクの間の実行時パフォーマンスの違いは、通常は無視できます。

2) プロファイル データを使用してプログラムのホットパスを最適化するプロファイリング コンパイラを使用する場合、(1) は当てはまりません。これは、静的リンクを使用すると、コンパイラがコードとライブラリ コードの両方を最適化できるためです。動的リンクでは、コードのみを最適化できます。ほとんどの時間がライブラリ コードの実行に費やされている場合、これは大きな違いを生む可能性があります。それ以外の場合は、(1) が引き続き適用されます。

私はすべて同じライブラリに依存するいくつかのアプリケーションを作成しようとしてきましたが、ダイナミックライブラリが私の最初の考えでした。それで私は「ライブラリ」を書き始めました。

次に、「ライブラリ」をコンパイルします

次に、ライブラリを使用するファイルをすばやく作成しました。

それから私はそれをコンパイルしようとしました

ただし、次のエラーでコンパイルされません。

私は非常に明白な何かが欠けていると思います、私を助けてください:)

DLL (ライブラリ) をコピーすると、アプリケーションがそれを取得してリンクするように、アプリケーションでフォルダーを監視することはできますか?

私は昔 C++ で同様のことをしましたが、.NET でライブラリを動的にリンクすることは可能ですか?

ありがとう

アプリケーションを64ビットCentOS5.4のmysqlclientライブラリにリンクしていますが、リンクエラーが発生します（-lmysqlclientが見つかりません）。ライブラリは/usr/ lib64 /mysql/にあります。

そして、ディレクトリはLinuxリンカーに正しく登録されているようです。

このマシンでアプリケーションをリンクできる唯一の方法は、ライブラリファイルへのフルパスを指定することです。これは私の場合は受け入れられません。ここで問題を引き起こす可能性があるのは何ですか？

ありがとう。

C言語で遅延バインディングを実現するにはどうすればよいですか？

Boostライブラリ、log4cxx、またはgoogleロギングライブラリの一部を含む一連のライブラリに依存する新しいC ++プロジェクトを開始します。プロジェクトが進化するにつれて、他のライブラリも進化します（まだ予測できません）。 。

32ビットシステムと64ビットシステムの両方で実行する必要があります。おそらく、必要なすべてのライブラリやsu特権が利用できるとは思わない、非常に多様なLinux環境で実行する必要があります。

私の質問は、これらすべてのライブラリに動的または静的にリンクしてアプリケーションを構築する必要があるかどうかです。

ノート：

（1）静的リンクは開発中に苦痛になる可能性があることを認識しています（コンパイル時間の延長、32ビットと64ビットの両方のクロスコンパイル、依存関係チェーンを下げてすべてのライブラリを含めるなど）が、テスト中ははるかに簡単です-ファイルを移動して実行するだけです。

（2）一方、動的リンクは開発段階で簡単になります-コンパイル時間が短く（32ビット開発環境から64ビットライブラリへの動的リンクを処理する方法がよくわかりません）、依存関係の連鎖に煩わされることはありません。一方、新しいバージョンの展開は醜い場合があります。特に、新しいライブラリが必要な場合（対象のマシンにsu権限がない、またはこれらのライブラリが利用できないという上記の条件を参照）。

（3）このトピックに関連する質問を読みましたが、どのアプローチが私のシナリオに最も適しているかを実際に理解できませんでした。

結論：

1. ご意見ありがとうございました！
2. 私はおそらく静的リンクを使用します。理由は次のとおりです。
• より簡単な展開
• パフォーマンス中の予測可能なパフォーマンスとより一貫した結果。テスト（このペーパーを参照してください：http：//www.inf.usi.ch/faculty/hauswirth/publications/CU-CS-1042-08.pdf）
• 指摘したように、静的と動的のコンパイルのサイズと期間はそれほど大きな違いではないようです
• より簡単でより速いテストサイクル
• 私はすべての開発者を維持することができます。私の開発者のサイクル。マシーン

実行中のプログラムに含まれるメモリ マップ領域を確認するために、/proc/self/maps からデータを読み取る単純な C プログラムを作成します。

プログラムの出力は次のようになります (ラベル付き)。

実行ビットと書き込み可能ビットから推測できるように、最初の 2 行はそれぞれプログラムのコード セグメントとデータ セグメントに関連付けられています。

しかし、私を混乱させているのは、libc.so のことです。libc.so からマップされた領域があります。そのうちの 1 つはプライベート ビットしかなく、書き込み、読み取り、または実行できません。もう 1 つの興味深い点は、ld.so には 3 つのセグメントしかないことです。libc.so のセグメントと比較すると、プライベート ビットのみがオンになっているセグメントが欠落しています。

では、4 つのセグメントが実際に何をしているのか知りたいのですが。カーネル 2.6.28、gcc 3.4.6、および binutils 2.19 で Ubuntu SMP を使用しています。

GStreamer ライブラリを使用するアプリケーションを開発しています。展開を容易にするために、すべての GStreamer ライブラリをローカル バンドルにまとめたいと考えています。このために、次のことを行う小さなスクリプトを作成しました。

• 依存関係を再帰的にトラバースする ( を使用otool -L)
• すべての依存関係をローカル ディレクトリにコピーする
• すべての依存パスを @executable_path に相対的に作成します (を使用install_name_tool)

(興味がある場合は、Ruby スクリプトを参照してください。)

gst_initただし、呼び出し時にランタイム エラーが表示されるようになりました。

これらのエラーは、ローカライズされたライブラリを使用した場合にのみ発生します。

install_name_tool の使用に関して、特定の「よくある落とし穴」はありますか? 誰かが私が間違っている可能性があることを知っていますか? 特定の詳細を知る必要がある場合は、お気軽にお問い合わせください。

更新
いくつか変更しました:

• 依存ライブラリについては、id ではなく dylib パスのみを変更するようになりました (のみを使用install_name_tool -changeし、 を変更しませんinstall_name_tool -id)。
• メイン ライブラリの場合、実行可能パス ( @executable_name/components/Video.dylib) に相対的な id 値を設定します。

これら2つの変更により、機能します。しかし、なぜそれが機能するのかは私にはまだ明らかではありません。「id」プロパティの意味を理解するのに苦労しています。パス名形式の識別子のようです。依存ライブラリ用に変更すると実行時エラーが発生するのはなぜですか? さらなる実験で、これらの質問に対する答えを見つけようとします...

ホスト アプリケーションがあり、プラグインを作成しました。プラグインを共有オブジェクト (foo.so など) にコンパイルすると、ホスト アプリケーションは dlopen 経由でそれをロードします。この場合、私のホスト アプリケーションは llvm の opt ツールです (ただし、それは質問にとって重要ではないと思います)。

プロファイリングを有効にしてプラグインをコンパイルしたい (つまりg++ -pg、gprof)。ただし、これを行うと、プロファイル出力ファイル gmon.out が作成されません。gprof は誰かがセットアップ ルーチンなどを呼び出すことを期待しているのかもしれません。

さまざまな理由から、ホスト アプリを -pg で再コンパイルすることは避けたいと考えています。ホスト アプリケーション opt をプロファイリングせずに、共有オブジェクト foo.so をプロファイリングできるかどうか興味があります。

他のプロファイリング ツールも調べました。HP の qprof はこの状況を処理できるはずですが、共有オブジェクト内の関数の名前を解決できません (非常に素朴な方法で addr2line にフォールバックします)。

ありがとう、ニック

共有オブジェクトを生成できるコードジェネレーターへのインターフェイスを作成しました。セクションヘッダーテーブルのサポートを実装する必要はありませんが、ELFファイル形式の大部分の複雑さが残っているためです。

GNU ldは、共有オブジェクトに対してリンクするためにセクションヘッダーを使用します。これは、セクションヘッダーのない共有オブジェクトに対してgccリンクを配置しようとすると、ライブラリにシンボルが存在していてもldがシンボルを見つけられないため、失敗することを意味します。

特定のシンボルが見つからない場合でも、リンクを成功させるためにコンパイラーをだますために使用できるトリックはありますか？

トラブルについての説明は次のとおりです。