私は C++ プロジェクトを 1 つ持っています。これは動的ライブラリです。Windows（Visual Studio 2012）でコンパイルすると、サイズが300 kB大きくなります。しかし、XCode を使用して Mac でコンパイルすると3.9 MB、バンドル内にバイナリが含まれます。
最適化レベルFastest, Smallest [-Os]オプションを選択しました。
Debug symbolsもオフになっています。
プロジェクトは同じです。唯一の追加のフレームワークはCocoa.framework、プロジェクトを正常にコンパイルするために必要な です。Cocoa.framework はそんなにリンクできますか?
これは悪いリンカーの仕事ですか？
これを LLVM GCC 4.2 または Apple LLVM Compiler 4.2 でコンパイルできます。サイズは同じです。
.bundle のサイズを小さくする方法はありますか?
プロジェクトからエクスポートされたシンボルが原因でこれが発生していると推測します。ここではデバッグ シンボルについて話しているのではなく、すべてのクラス、メソッド、コンストラクター、例外ハンドラー アンワインド セグメントなどのシンボル テーブル エントリについて説明します。後者のカテゴリは、例外と標準ライブラリを使用するプロジェクトでそれらの多くを占めています。
多くのテンプレートでSTL、ブースト、またはその他のものを使用している場合、それらを使用したすべてのタイプ（多くの場合、メソッドだけでなくクラス全体）の特殊化もあり、弱いリンケージがあります。シンボル名の長さは、テンプレートの展開とパラメーター型の C++ 名マングリングによって膨大になります。
Windows DLL をコンパイルするときは、コンパイラ ディレクティブ (多くの場合マクロを使用) またはリンカー シンボル エクスポート リストを使用して、シンボルを明示的にエクスポートする必要があります。DLLExport
MacOSX および ELF ベースの *NIX システムでは逆で、デフォルトですべてエクスポートされます。リンカーは、モジュールが何にリンクされているかを知る方法がないため、どのモジュールが有用かどうかを知る方法がありません。実際には、アプリケーションは通常、main未解決のシンボルをエクスポートするだけで済みます。
としてマークされた C++ クラス メンバーも区別されませんprivate。これらのシンボルも取得します。
Apple からのこのリファレンスでは、シンボルの可視性を制限する方法について説明しています。以前は確かにこれを行うことができましたgccが、同等の for をざっと見てみると、clangそこでは十分にサポートされていないことがわかります。