質問: linuxでバイナリのサイズを減らすためのコンパイル時間の考慮事項は何ですか? 1つのユーティリティをコンパイルし、linuxシステムでバイナリを作成しました。しかし、このバイナリのサイズは2.3 mbであり、このバイナリのサイズを減らす必要があります。バイナリにstripを適用してみましたが、十分ではありません。それで、ユーティリティのコンパイル中に適用できるオプション(おそらく構成)はありますか?お返事ありがとうございます。
回答: 次の方法を使用して、実行可能ファイルのサイズを減らすことができます。 実行可能ファイルがデバッグシンボルなしでコンパイルされていることを確認してください。これは、メイクファイルのgccコマンドラインオプションにフラグ-gが存在する場合に発生します。このような実行可能ファイルを簡単にデバッグできるため、これは通常デフォルトです。ユーティリティstripを使用して、既存の実行可能ファイルからデバッグシンボルを削除できます。多くの場合、これだけで実行可能ファイルのサイズを2倍以上、場合によっては10倍も減らすことができます。 必要なすべてのライブラリを動的にコンパイルします(特にlinuxのcランタイムライブラリglibc)。静的コンパイル(-s)は依存関係を回避するのに適していますが、実行可能ファイルのサイズが大幅に増加するという代償を伴います。たとえば、実行可能ファイルにlibxml2が必要な場合は、-lxml2をgccコマンドラインに追加して、libxml2を動的にリンクします。このアプローチの欠点は、必要なライブラリがターゲットシステムにインストールされていない場合、実行可能ファイルがクラッシュすることです(最初にsudo apt-get install libxml2を実行する必要があります)。 サイズ-osによる最適化を有効にします。ただし、通常のゲインは非常に小さく、5%〜10%を超えることはめったにありません。 upx を使用して実行可能ファイルを圧縮します(sudo apt-get install upx-uclを使用してインストールします)。 upxは、intelプラットフォームだけでなく、arm、mips、powerpcなどの他の多くのプラットフォームのパッキングをサポートします。upxはサイズを大幅に縮小する可能性がありますが(2x-5x)、盲目的に使用しないでください。標準の実行可能ファイルとは異なり、upxで圧縮された実行可能ファイルは同じキャッシュページを共有できません。たとえば、プログラムのサイズが2mbで、100コピーを開始した場合、約2mbのメモリしか消費しません。カーネルはキャッシュされたページを再利用します。 upxで圧縮して1mbとすると、100コピーを開始すると、200mbのメモリが消費されます。ただし、ディスクから1 mbを読み取るだけで済み、upxの解凍が非常に高速であるため(ディスクからの読み取りよりもはるかに高速)、最初のコピーの開始時間が大幅に短縮されます。