Goでアプリケーションをビルドし、Amazon Linux 2（AL2）やAmazon Linux 2023（AL2023）などの環境で実行しようとした際、glibc依存エラーに悩んだことはありませんか？
その原因の1つは、Goバイナリが実行環境のglibcバージョンに依存してしまうケースです。
その対策として、「CGO_ENABLED=0」でのビルドが非常に有効です。
🔍 なぜCGO_ENABLED=0が必要なのか？
✅ Goバイナリのglibc依存問題
Goは通常、CGO（C言語ライブラリとの連携） が有効な状態でビルドされます。
その場合、ビルド時のglibcバージョンに依存するバイナリが生成されます。
💥 典型的なエラー
/lib64/libc.so.6: version 'GLIBC_2.28' not found
- AL2（glibc 2.26）など古い環境では、このようなエラーが発生しやすいです。
✅ devcontainerやローカルのビルド環境も影響
例えば、**Debian Bookwormベースのdevcontainer（glibc 2.37）**などでビルドした場合、
ビルド後のGoバイナリはglibc 2.37依存となり、AL2/AL2023で動かなくなる可能性があります。
🚀 【解決】CGO_ENABLED=0を指定してビルド
これを回避するには、CGOを無効化して「完全にglibc非依存」な静的リンクバイナリを作成します。
CGO_ENABLED=0 go build -ldflags="-w -s" -o your_app
- glibc依存が完全に排除され、AWS EC2上のAL2/AL2023やAlpineなどほぼ全てのLinuxで動作可能なGoバイナリが完成します。
🎯 いつ使うべきか？
- APIサーバー、CLIツール、バッチ処理などGoのみで完結するアプリケーション
- AWS Lambda / ECS / EC2にGoバイナリを配布する場合
- ホストOSやDocker環境が異なる複数環境間でバイナリを共有する場合
⚠️ 注意：CGOが必要なケースもある
-
github.com/mattn/go-sqlite3などCライブラリ依存のGoパッケージを使う場合は CGO有効が必須
その場合は、ターゲットOSのglibcに合わせたビルド環境（Dockerなど）でビルドする必要があります。
💡 Tips
-
ldd your_appコマンドで「not a dynamic executable」と表示されれば、glibc非依存バイナリです - AL2やAL2023間でバイナリをそのまま共有可能
📝 まとめ
- Goバイナリはデフォルトでglibc依存が発生する
- CGO_ENABLED=0 でビルドすることで、Linux間のバージョン差を気にせずに安全に配布可能
AWS運用時は特に CGO_ENABLED=0 go build を基本にするのがベストプラクティス です！