問題タブ [dynamic-linking]

重複の可能性: C++ アプリケーションの
静的リンクと動的リンク- ライブラリに静的リンクと動的リンクのどちらを使用する必要がありますか?

静的リンクと動的リンクを選択する前に注意すべき点は何ですか?

静的ライブラリに対して静的にリンクする共有オブジェクトをコンパイルする際に、多くの問題が発生しました。この問題は、x84_64 プラットフォームでのみ発生します。x86_32 で同じコンパイル作業を行う場合、問題はありません。

おそらくこれは OS 固有の GCC 構成の問題ですが、私の調査では、GCC が x86_64 プラットフォームでどのように機能するかが示されています。とにかく、Ubuntu 10.04 x86_64 で gcc 4.4.3 を使用しています。

問題はどのように修正されますか?... すべての静的ライブラリの依存関係が -fPIC でコンパイルされていることを確認します。

質問 1: -fpic と -fPIC の違いは何ですか (明らかに -fPIC は x86 でより多くの命令を生成します)。x86_64 コンテキストでは、後のタイプの方が関連性が高いのはなぜですか?

質問 2:私の仮定では、静的コードに対してリンクする場合、リンク時に関数をバイナリに配線しているのに、「位置に依存しないコード」機構が提供する間接的なレベルが必要なのはなぜですか?

質問 3:共有オブジェクトを静的アーカイブにリンクするために x86 が -fpic / -fPIC を必要としない場合、なぜ x86_64 で必要なのですか?

質問 4:必要な場合でも、暗黙的に提供されないのはなぜですか? 重大な変更は絶対にダメだと思っていた

実行時にアセンブリを動的にロードすることで、アセンブリをアンロードできないという制限があることを認識しています。代わりに、これが要件である場合は、代わりに他のアプリケーションドメインにモジュールをロードしてから、ドメインの境界を越えてコードを実行することをお勧めします。

この開発プロセスを簡単にして、このシナリオで作業するにはどうすればよいですか？どのようなツールまたはフレームワークが利用できますか？

動的にリンクされたELFバイナリがあり、特定のライブラリ呼び出しをオーバーライド/リダイレクトしたいとします。でこれを実行できることはわかっていますLD_PRELOADが、環境に依存せずにバイナリで永続的であり、setuid / setgidバイナリで機能するソリューションが必要ですが、いずれもLD_PRELOAD実現できません。

私がやりたいのは、追加のオブジェクトファイルからコードを追加し（必要に応じて新しいセクションで）、これらのオブジェクトファイルのシンボルをバイナリのシンボルテーブルに追加して、新しく追加されたバージョンのコードが代わりに使用されるようにすることです。共有ライブラリコード。これは、既存のコードで実際に再配置を実行しなくても可能であると思います。それらが同じファイルにある場合でも、これらは実行時に通常のPLTの方法で解決できるはずです（データではなく関数のみを気にする価値があります）。

「これはやりたくない！」という言葉に沿って答えないでください。または「それはポータブルではありません！」私が取り組んでいるのは、バイナリをわずかにABIと互換性のない代替共有ライブラリ実装とインターフェースする方法です。問題のプラットフォームは、重要な場合はi386-linux（つまり、32ビット）です。何が可能かを間違えない限り、ELFファイルを解析してハックを実行するツールをいくつか書くことはできますが、GNUリンカーやその他のツールを使用して、新しいコードを記述せずにこれを実現する素晴らしい方法があると思います。

一般：Windows、OS X、およびLinuxでネイティブの静的にリンク可能なライブラリとしてサポートしたいBoostライブラリを使用する標準準拠のC ++ APIがあり、WindowsおよびMonoで.NET用にラップしたいOSXおよびLinuxで。

詳細：現在、すべてのプラットフォーム用にネイティブにコンパイルしています。これは、標準のC++とBoostを使用した後のことです。また、WindowsでC ++ / CLI用にコンパイルして実行することもできましたが、Boost.DLLを使用せざるを得ませんでした。次のステップ*nixシステムで共有ライブラリを使用しようとしたことがないため、どこから始めればよいかわかりません。BoostがLinuxで共有ライブラリを提供していることは知っていますが（OS Xでも同じことが当てはまると思います）、これらはVisualStudioでコンパイルされたC++ / CLI実行可能ファイルで自動的に機能しますか、それとも何らかの作業が必要ですか？MonoDevelop用のC++/ CLIコンパイラはありませんが、おそらくVisualStudiosでコンパイルされたCLIは問題なく動作します...動的にリンクされたライブラリが私を混乱させています。

次の状況があるとします。

• program動的に依存するという名前のプログラムlibfoo.so
• libfoo.soそれは何にも依存していません (まあ、それは何かに依存していますが、それはlibstdc++省略できると思います)

program完璧に動作します。

突然、コードが変更され、一部の関数が別のライブラリによって提供される関数をlibfoo内部的に使用するようになりました。func_bar()libbar.so

libfoo.soが再コンパイルされ、依存するようになりましたlibbar.so。programは変更されず、 のみに依存しlibfoo.soます。

今私が実行するprogramと、彼が見つけることができないと不平を言いますfunc_bar()。

ここに私の質問があります：

• libfoo.soインターフェイスは変更されず、その実装のみが変更されました。と明示的にリンクするprogram必要があるのはなぜですか?libbar.so
• 依存関係ツリーは再帰的ではありませんか? libfoo.soに依存しているためlibbar.so、再コンパイルせずに の依存関係リストにlibbar.so自動的に追加されたと思います。しかし、そうではないことを示しています。programldd program

ライブラリの依存関係が変更されるたびに、そのライブラリに依存するすべてのバイナリを再コンパイル (再リンク)しなければならないのは奇妙に思えます。これを防ぐためにここにどのような解決策がありますか?

私は静的リンクと動的リンクの違いを知っています、そしてこれは違いを尋ねる別の質問ではありません（私はそれらを見て読んだことがあります）。ダイナミックリンクのセキュリティについての質問は見つかりませんでした。

私は「エキスパートCプログラミング」という本を読んでいます。リンクに関する素晴らしいセクションがあります。私の理解が正しければ、ダイナミックリンクの欠点はセキュリティの低下ではないでしょうか。プログラムが安定した適切なライブラリを提供するためにOSに依存している場合、OS上のライブラリが感染/悪意のあるものになる可能性があります。汚染されたライブラリを防ぐためにプログラムでできることはあまりありません。

これは正しいですか？

C++ で記述されたサーバー アプリケーションがあります。起動後、x86 Linux (Ubuntu 8.04、GCC 4.2.4) で約 480 KB のメモリを使用します。480 KB は過剰な量のメモリだと思います。サーバーはまだ何も実行しておらず、クライアントもサーバーに接続していません。(480 KB が大量のメモリであると考える理由を説明している以下のコメントも参照してください。) 初期化中にサーバーが行う唯一のことは、1 つまたは 2 つのスレッドの生成、いくつかのソケットのセットアップ、およびその他の単純なことです。非常にメモリ集約的です。

VM サイズではなく、実際のメモリ使用量について話していることに注意してください。アイドル状態のラップトップでサーバーの 100 個のインスタンスを起動し、サーバー インスタンスを起動する前後のシステム メモリの使用量を「空き」で測定することで測定しました。私はすでにファイルシステムのキャッシュなどを考慮に入れています。

いくつかのテストの後、サーバー自体が何もしない場合でも、C++ ランタイムの何かが原因でサーバーがこれだけ多くのメモリを使用しているように見えます。たとえば、挿入すると

直後の

その場合、メモリ使用量はインスタンスあたり 410 KB のままです。

私のアプリケーションは Curl と Boost だけに依存しています。私は C プログラミングの経験がかなりあり、C ライブラリを使用するまでは、C ライブラリがメモリ消費を増加させる傾向がないことを知っています。

私が見つけた他のもの：

• 単純な hello world C アプリは、約 50 KB のメモリを消費します。
• Curl にリンクされているが Curl を使用していない単純な hello world C アプリも、約 50 KB のメモリを消費します。
• シンプルな hello world C++ アプリ (Boost なし) は、約 100 KB のメモリを消費します。
• 一部の Boost ヘッダーを含むが実際には Boost を使用しない単純な hello world C++ アプリは、約 100 KB のメモリを消費します。「nm」を使用して実行可能ファイルを検査すると、Boost シンボルが表示されません。

したがって、私の結論は次のとおりです。

1. Gcc は未使用の Boost シンボルを破棄します。
2. アプリが Boost を使用している場合、C++ ランタイムの何か (おそらく動的リンカー) が原因で大量のメモリが使用されます。しかし、何？これらが何であるかを知るにはどうすればよいですか? また、それらについて何ができるでしょうか?

数年前に C++ 動的リンカーの問題について KDE で議論されたことを覚えています。当時の Linux C++ 動的リンカーは、KDE ​​C++ アプリの起動時間を遅くし、大量のメモリを消費していました。私の知る限り、これらの問題は C++ ランタイムで修正されています。しかし、私が目にしている過度のメモリ消費の原因は、似たようなものでしょうか?

gcc/動的リンクの専門家からの回答は大歓迎です。

興味のある方のために、問題のサーバーは Phusion Passenger のロギング エージェントです: https://github.com/FooBarWidget/passenger/blob/master/ext/common/LoggingAgent/Main.cpp

Objective-Cで、クラスの名前が文字列である場合にクラスを取得してメッセージを送信する方法はありますか？たとえば、次のような関数funcはありfunc(@"NSString") == [NSString class]ますか？

これを知りたいのは、作業中の言語用のダイナミックリンカーライブラリを構築していて、Objective-Cライブラリへのインターフェイスを持たせたいからです。

Linux で OpenGL を使用するほとんどのアプリケーション (およびライブラリ)は、API に対して動的にリンクするのではなく、APIlibGL.soを使用して実行時にロードします。dlopen

なぜ彼らはこれを行うのですか？

私が想像できる唯一の理由は、グラフィック ドライバー ベンダーがlibGL異なるlibGL. (うーん、なぜそれらは ABI 非互換である必要があるのですか? また、そうであるとしても、なぜそれらを経由してロードするdlopenとこの問題が修正されるのでしょうか?)

とはいえ、それなりの理由があるのなら、私もそうしたい。を介してすべての OpenGL 関数をロードするオープンソースの C/C++ コードへのリンクを持っている人はいますdlopenか?