こんにちは！日々のC言語コーディング、楽しんでいますか？
「C言語のプログラムといえば、まずは `main()` 関数から実行される」――これは、すべてのプログラマが最初に学ぶ絶対的な真実です。私も駆け出しの頃は、例外なくそう信じ切っていました。
しかし、大規模なシステムやライブラリの設計に踏み込むと、ふとこんな疑問にぶつかります。
「おい、`main()` が呼ばれるより 前 に、どうしても初期化しておきたい設定があるんだが……どうすればいいんだ？」
例えば、ログ出力システムの事前準備、独自メモリプールの確保、あるいは暗号化ライブラリの鍵のロードなど。「`main()` の先頭で初期化関数を呼べばいいじゃないか」と思いますよね？ でも、それが「何十個もあるサードパーティ製ライブラリの組み合わせ」だったり、「動的ライブラリ (`.so` / `.dll`) がロードされた瞬間」だったりしたらどうでしょう。呼び出し忘れのリスクが跳ね上がり、コードは一気にスパゲッティ化します。
ここで登場するのが、GCCやClangが持つ強力なコンパイラ拡張機能、`__attribute__((constructor))` です。
これを知れば、「プログラムの起動やライブラリのロード」というOSとランタイムの境界線を、あなたの意のままにコントロールできるようになります。これをマスターすれば、毎日のコーディング、そしてアーキテクチャ設計が劇的に優雅で楽になりますよ。さあ、その秘密を一緒に紐解いていきましょう！
—
1. `__attribute__((constructor))` とは何か？（ツールの役割と本質）
私たちが普段書くC言語のソースコードは、コンパイルされてバイナリ（実行ファイルや共有ライブラリ）になります。OSがそのバイナリをメモリ上にロードし、CPUに実行権を渡すとき、実は `main()` 関数に到達するまでに、いくつかの「隠された初期化処理」が裏側で走っています。
Cの標準ランタイム（crt0 / crt1.o など）は、大域変数（グローバル変数）の初期化やスレッドローカルストレージの準備などを行ってから `main()` を呼び出します。
GCCやClangは、この「ランタイムの初期化フェーズ」に、プログラマが書いた任意の関数をフックして割り込ませる機能を提供しています。それが `__attribute__((constructor))` です。
なぜこの機能が現場で「神」扱いされるのか？
1. 完全なカプセル化: ライブラリを利用する側（`main()` を書く人）は、そのライブラリの初期化関数を呼ぶ必要すら忘れていても、勝手に初期化が完了します。
2. プラグイン機構の簡素化: `dlopen()` などで動的ライブラリがプロセスにロードされた瞬間にコードが走るため、プラグインの自動登録システムなどが驚くほど美しく書けます。
3. 終了処理の対抗馬 (`destructor`): もちろん、プログラム終了時やアンロード時に走る `__attribute__((destructor))` もペアで用意されています。
—
2. 開発環境のセットアップ
特別なツールは必要ありません。Linux環境（UbuntuやCentOSなど）または macOS があれば、今すぐ手元のターミナルで試せます。ここでは、現代の標準であるGCCまたはClangを用意してください。
動作確認用ディレクトリの作成
まずは作業用のディレクトリを作成し、移動しましょう。
作業用ディレクトリを作成して移動
mkdir -p c_constructor_demo
cd c_constructor_demo
—
3. 精度高い「HelloWorld」的動作確認：mainより先を生きる関数
百聞は一見に如かず。実際に `main()` よりも先に実行されるコードを書いてみましょう。
サソースコードの作成 (`main.c`)
以下のコードをエディタで作成してください。
include
/
- コンストラクタ属性の付与
- __attribute__((constructor)) を指定することで、
- OSがmain関数を呼び出す前に、この関数が自動実行されます。
/
__attribute__((constructor)) void pre_main_initialization(void) {
printf(“[DEBUG] -> main() が呼ばれる前の初期化処理が走りました！\n”);
}
/
- デストラクタ属性の付与
- __attribute__((destructor)) を指定すると、
- main関数が終了した後（あるいはプログラムの終了時）に実行されます。
/
__attribute__((destructor)) void post_main_cleanup(void) {
printf(“[DEBUG] -> main() が終了した後のクリーンアップ処理が走りました！\n”);
}
int main(void) {
printf(“[INFO] -> 実際の main() 関数が実行されました。\n”);
return 0;
}
コンパイルと実行
ターミナルで以下のコマンドを実行し、動作を確認します。
gccを使ってコンパイル
gcc -o demo main.c
実行
./demo
実行結果のログ
[DEBUG] -> main() が呼ばれる前の初期化処理が走りました！
[INFO] -> 実際の main() 関数が実行されました。
[DEBUG] -> main() が終了した後のクリーンアップ処理が走りました！
どうですか？ `main()` の中には初期化用の関数を一切書いていないにもかかわらず、その上下できちんと関数がフックされて実行されています。これが、ランタイムの隙間を縫うコンパイラマジックの正体です。
—
4. さらに深く：動的ライブラリ（`.so`）でのロード時フックと初期化順序の制御
基礎ができたら、次は実務で最も真価を発揮する「動的ライブラリのロード時実行」と、複数の初期化関数がある場合の「実行順序の制御（Priority指定）」に進みましょう。
複数の初期化関数がある場合、デフォルトではどの順番で呼ばれるか保証されません（リンク順に依存します）。しかし、大規模なライブラリ群では「Aを初期化した後に、Bを初期化したい」という明確な依存関係があります。これを制御するのが `priority` 引数です。
優先度付きコンストラクタの実験コード (`plugin.c`)
以下のコードは、数値が小さいほど「より早く（優先的に）」実行されることを示します。
include
/
- 優先度「101」の初期化関数
- 優先度の数値が小さいほど、より早いタイミングで実行されます。
/
__attribute__((constructor(101))) void init_first(void) {
printf(“[INIT] 優先度 101: 最優先の基盤システム初期化\n”);
}
/
- 優先度「202」の初期化関数
- 101の処理が終わった後に実行されます。
/
__attribute__((constructor(202))) void init_second(void) {
printf(“[INIT] 優先度 202: 依存関係のある上位モジュールの初期化\n”);
}
/
- 優先度を指定しない場合（標準のコンストラクタ）
/
__attribute__((constructor)) void init_default(void) {
printf(“[INIT] 優先度 未指定: 通常のコンストラクタ\n”);
}
これを共有ライブラリ（`.so` ファイル）としてコンパイルし、別のプログラムから動的にロード（`dlopen`）してみましょう。
動的ライブラリのビルドコマンド
共有ライブラリ（Position Independent Code付き）としてコンパイル
gcc -shared -fPIC -o libplugin.so plugin.c
ロード側のテストプログラム (`loader.c`)
include
include
include
int main(void) {
printf(“[LOADER] プログラム開始。これから動的ライブラリをロードします…\n”);
// libplugin.soを動的にロード (RTLD_NOWで即座にシンボルを解決)
void handle = dlopen(“./libplugin.so”, RTLD_LAZY);
if (!handle) {
fprintf(stderr, “Error: %s\n”, dlerror());
return 1;
}
printf(“[LOADER] 動的ライブラリのロードが完了しました。\n”);
// ライブラリをアンロード
dlclose(handle);
printf(“[LOADER] プログラム終了。\n”);
return 0;
}
ビルドと実行（動的リンクのテスト）
`-ldl` フラグをつけてコンパイルし、実行します。
ローダーをコンパイル (-ldl は dlopen を使うために必要)
gcc -o loader loader.c -ldl
実行
./loader
実行結果のログ
[LOADER] プログラム開始。これから動的ライブラリをロードします…
[INIT] 優先度 101: 最優先の基盤システム初期化
[INIT] 優先度 202: 依存関係のある上位モジュールの初期化
[INIT] 優先度 未指定: 通常のコンストラクタ
[LOADER] 動的ライブラリのロードが完了しました。
[LOADER] プログラム終了。
見てください！ `dlopen()` が実行された「その瞬間」に、OSのダイナミックローダがライブラリ内の `__attribute__((constructor))` を検出し、指定した優先度（101 -> 202 -> 未指定）の順序通りに自動実行しています。
この仕組みを使いこなせば、プラグインファイルをフォルダに放り込むだけで勝手に自己登録を済ませる、極めて拡張性の高いアーキテクチャを構築できるようになります。
—
5. 現場のプロとしての注意点（落とし穴とベストプラクティス）
非常に強力なこの機能ですが、シニアエンジニアとしていくつか重要な「注意点（罠）」も伝えておきます。
1. ポータビリティ（移植性）の限界
`__attribute__((constructor))` はGCCおよびClang（およびそれらと互換性のあるコンパイラ）の拡張機能です。完全な標準C（C99/C11など）の機能ではないため、もし厳格なMSVC（Microsoft Visual C++）環境をサポートする場合は `#pragma section` や `#pragma comment(linker, …)` などの別機構をラップして吸収する必要があります。
2. 初期化順序の曖昧さに頼らない
異なるソースファイル間で指定した優先度が同じ場合、リンクされる順番によって実行順序が前後することがあります。「どうしても順番を保証したいもの同士」は、同じファイル内に書くか、優先度を明確に離して設計してください。
3. 副作用の塊にしない
コンストラクタ内で複雑すぎる処理（ネットワークの同期通信や、重いDBマイグレーションなど）を行うと、プログラム起動やライブラリロードがフリーズしたようになり、デバッグが極めて困難になります。「メモリの確保」「設定の読み込み」「関数ポインタの登録」といった、軽量で確実な初期化に絞るのが美しい設計です。
—
おわりに
今回は、C言語の裏側を支配する `__attribute__((constructor))` の世界へご案内しました。
「main関数の前でコードを実行する」という、一見すると地味なテクニックですが、これを理解しているかどうかが、単なる「コードを書く人」と「堅牢なシステムを設計するアーキテクト」の分かれ道になります。
この知見を武器に、あなたの手元のコードやフレームワークを、もっとスマートに、もっとエレガントに進化させてみてください。毎日のコーディングが、今までよりもっとワクワクするものになるはずです。それでは、また次の深淵なる低レイヤの世界でお会いしましょう！