はじめに：なぜ「MinGW-w64バイナリの肥大化」は実務上の脅威となるのか
テックリードの皆さん、日々のネイティブアプリケーション開発において、こんな課題に直面していないだろうか。「ローカルテスト用にビルドしたバイナリが、気づけば数MB〜数十MBに膨れ上がっている」「CI/CDパイプラインから生成される成果物のサイズが肥大化し、アーティファクトのストレージ圧迫やダウンロード速度の低下を招いている」、そして何より「ユーザーに配布するインストーラーのサイズを1バイトでも削りたい」というプレッシャーだ。
特にWindows環境において、MSYS2/MinGW-w64を用いたGCCツールチェーンによるビルドは非常に強力だが、デフォルト設定のままでは、デバッグシンボル、未使用の例外処理テーブル、静的リンクされたランタイムの冗長なコードがバイナリの隅々にまで残り続ける。
ネットを検索すれば「`-O3` をつけろ」「`strip` コマンドを叩け」といった表層的な情報はいくらでも見つかる。しかし、それだけでは現代のモダンなC/C++プロジェクトで要求される「極限の軽量化」には到底届かない。
本記事では、MSYS2環境を骨の髄まで理解し、コンパイラの内部挙動やリンカの最適化メカニズム（LTO, ガルベッジコレクション, スタティックリンクの罠）を熟知したアーキテクトの視点から、バイナリサイズを極限まで削ぎ落とすプロの実践テクニックを体系的に伝授する。
—
1. コンパイラ・リンカフラグの極限チューニング：何がバイナリを肥大化させているのか
まずは、GCCとGNU Binutilsが裏側で何をやっているのかを理解することから始めよう。デフォルトのビルドでは、バイナリの中に「実行に全く不要なメタデータ」が大量に含まれている。これを根底から断つためのフラグ戦略を解説する。
`-Os` と `-O3` の罠：サイズ最適化の真実
多くのエンジニアは「とにかく最速にしたいから `-O3` だ」と思考停止でフラグを入れがちだ。しかし、`-O3` はコードのインライン展開（Loop UnrollingやFunction Inlining）を積極的に行うため、バイナリサイズが劇的に肥大化する。
サイズを最優先（Size optimization）にする場合は、`-Os` を選択すべきだ。`-Os` はキャッシュ効率を維持しつつ、コードサイズを最小化する最適化パスを優先して実行する。さらに一歩進めるなら、`-Oz`（Clang系）や、GCCでの限界突破として `-O2` をベースにサイズ関連のフラグを手動で絞るアプローチもあるが、基本は `-Os` がファーストチョイスとなる。
リンカレベルでのセクション単位の分離と削除
C/C++のコンパイラは、デフォルトではソースファイル（翻訳単位）単位でオブジェクトコードを生成する。つまり、ファイル内の「たった1つの使われていない関数」のために、そのファイル全体のコードがバイナリに残留してしまう。
これを解決するのが、以下の3種の神器だ。
1. `-ffunction-sections`：関数ごとに独立したセクションへ分割する
2. `-fdata-sections`：変数ごとに独立したセクションへ分割する
3. `-Wl,–gc-sections`：リンカが参照されていないセクションをごっそり削ぎ落とす
この組み合わせにより、静的リンクした巨大なサードパーティライブラリであっても、「実際に呼び出された関数・変数」だけが最終的なバイナリに残留し、それ以外は完全に消去される。
—
2. 実践：Makefile / CMake による最小化ビルド構成のベストプラクティス
口頭や単発のコマンド実行ではなく、チーム開発でこの最適化を強制・共有するための「CMake プリセットおよび設定ファイル」の模範解答を提示する。
以下の `CMakePresets.json` は、開発用（Debug）と、極限までサイズを削った配布用（Release-MinSize）を明確に分離し、チーム全員が同一の最適化されたバイナリを再現できるようにするための設定である。
`CMakePresets.json` （チーム共有用設定）
{
“version”: 3,
“cmakeMinimumRequired”: {
“major”: 3,
“minor”: 20,
“patch”: 0
},
“configurePresets”: [
{
“name”: “mingw-release-min”,
“hidden”: false,
“displayName”: “MinGW-w64 Extreme MinSize Release”,
“description”: “バイナリサイズを極限まで削るためのMSYS2/MinGW用プリセット”,
“generator”: “Ninja”,
“binaryDir”: “${sourceDir}/build/release-min”,
“cacheVariables”: {
“CMAKE_C_COMPILER”: “x86_64-w64-mingw32-gcc”,
“CMAKE_CXX_COMPILER”: “x86_64-w64-mingw32-g++”,
“CMAKE_BUILD_TYPE”: “Release”,
/ C/C++共通の極限サイズ最適化フラグ /
“CMAKE_C_FLAGS_RELEASE”: “-Os -ffunction-sections -fdata-sections -fno-unwind-tables -fno-asynchronous-unwind-tables”,
“CMAKE_CXX_FLAGS_RELEASE”: “-Os -ffunction-sections -fdata-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-exceptions -fno-rtti”,
/ リンカオプション：未使用セクションの削除、デバッグ情報の完全排除、LTO(リンク時最適化)の有効化 /
“CMAKE_EXE_LINKER_FLAGS_RELEASE”: “-Wl,–gc-sections -Wl,–strip-all -flto”
}
}
]
}
上記設定におけるプロのこだわりポイント
- `-fno-exceptions -fno-rtti`: 例外処理やRTTI（実行時型情報）が不要な純粋なC++プロジェクト、またはC言語の場合、これらを無効化することでランタイムサポートコードのフットプリントを劇的に削れる。
- `-fno-unwind-tables -fno-asynchronous-unwind-tables`: スタックトレース生成用のアンワインドテーブルを削除。例外を投げない設計であれば不要であり、サイズ削減に直結する。
- `-Wl,–strip-all`: リンカの段階でシンボルテーブルとリロケーション情報を完全にパージする。
—
3. MSYS2環境における「隠れた技術」：LTOと不要シンボルの完全排除
バイナリサイズ削減の最終段階として、MSYS2のツールチェインのポテンシャルを極限まで引き出すテクニックを紹介する。
1. リンク時最適化（LTO: Link-Time Optimization）の強制
通常のコンパイルはファイル単位で行われるため、ファイル間を跨いだインライン展開やデッドコード検出ができない。しかし、コンパイル時に中間表現（IR）を保持させ、リンク時にGCCのバックエンド（`ar` や `ld` の代わりにプラグイン経由でGCCを呼ぶ）で全体最適化を行う `-flto` を有効にすると、さらなるコードの圧縮と高速化が同時に達成される。
MSYS2環境でLTOを確実に機能させるには、アーカイバやランlibtoolの設定もLTO対応版（`gcc-ar`, `gcc-ranlib`）を使う必要がある点に注意せよ。
2. `strip` コマンドの正しい流儀
ビルド後に手動でサイズを削る場合、単なる `strip` では不十分な場合がある。以下のコマンドを実行することで、PEフォーマット（Windows実行ファイル）特有の不要なエクスポートセクションやデバッグディレクトリを完全に消し去ることができる。
デバッグシンボルだけでなく、すべてのローカルシンボルとコメントセクションを完全パージ
x86_64-w64-mingw32-strip –strip-all –remove-section=.comment –remove-section=.note.gnu.gold-version target_app.exe
—
4. 開発効率を底上げするMSYS2/MinGW環境の神設定・ショートカット
ここからは、コンパイル待ちの時間や、煩雑なビルド環境の切り替えストレスをゼロにするための開発環境ハックを伝授する。
1. ターミナル高速化：Windows Terminal + MSYS2 UCRT64 の最速起動プロファイル
開発スピードのボトルネックは「ツールの起動遅延」にもある。以下のJSON断片を Windows Terminal の `settings.json` の `profiles.list` に追加し、ショートカットキー（例: `Ctrl + Shift + M`）を割り当てておけ。一瞬でUCRT64環境が立ち上がり、ビルド作業へ移行できる。
{
“guid”: “{0