30代エンジニアの備忘録

（2026年5月時点）ライブラリの取り込みには大きく 静的リンク と 動的リンク があります。配布後に「開発者がビルドへ焼き直す」か「実行環境側が .so を差し替える」かという更新の契約が違う、と先に押さえると迷子になりにくいです。ここではそれぞれの流れと、デスクトップ Linux と組み込み（ベアメタル／RTOS／組込みLinux）での 前提の違い を中心に整理します。

静的リンクは、ビルド時にライブラリの機械語を実行ファイル側へ取り込む方式です。アーカイブ（.a）はリンク入力として使われ、最終バイナリは 自分自身にコードを持つ分厚い形になりがちです。

静的リンクの仕組み

# 意思決定メモ：`gcc -static` は「libc を含め極力すべて静的」の方向になり、glibc と相性・ポリシーで詰むことがあります。
# まずは「この .a のみ明示リンク」など部分静的／動的ハイブリッドも検討対象。

#（例）自分で作った .a を明示的に渡してリンクする
gcc -c utils.c -o utils.o
ar rcs libutils.a utils.o
gcc main.o libutils.a -o myapp_static

• 向き：配布単体で完結させたい、実行環境側に .so を置けない／置きたくない
• 注意：複数プロセスで同一ライブラリを共有実行する場面では、動的リンクほど mmap で実体共有しやすい、という側面があります（ワークロード依存）

動的リンクは、実行時にローダーが .so など共有ライブラリをマップし、printf の実体などを実行時に載せます。検索順序や SONAME が絡んで 実行環境差 が出やすい点は押さえておくとよいです。

動的リンクの仕組み

# 共有ライブラリの作成
gcc -c -fPIC utils.c -o utils.o
gcc -shared -o libutils.so utils.o

# 動的リンクでビルド
gcc main.c -L. -lutils -o myapp

# LD_LIBRARY_PATH の例（開発や一時運用では便利だが恒久運用は rpath/runpath なども検討）
LD_LIBRARY_PATH=. ./myapp

• 向き：バイナリを小さく保ち、アップデートをライブラリ差し替え中心に進めたい
• 注意：環境側のライブラリ探し／バージョン整合に弱い構成は「依存地獄」になりやすい（Linux でもパッケージや rpath で整理することが多い）

PATH と rpath の具体例： 開発中だけ LD_LIBRARY_PATH=/opt/mylib:$LD_LIBRARY_PATH ./myapp で繋ぐのは手早い一方、恒久運用なら patchelf で RPATH を埋め込むか、既定の libdir へ並べて ldconfig 管理する、で「検索順の契約」を固定しやすいです。

静的リンクと動的リンクの比較

• ファイルサイズ：静的→大きい / 動的→小さい
• ライブラリ依存：静的→なし（自己完結） / 動的→実行環境に必要
• メモリ効率：静的→プロセスごとに複製 / 動的→プロセス間で共有可能
• 更新の容易さ：静的→再ビルド必要 / 動的→ライブラリ差替えのみ
• 起動とロード：静的はローダ処理が単純に見えることがある一方、サイズ増。動的は起動時の解決がある分オーバーヘッドがある（体感はワークロード次第）

ベアメタル環境（RTOS・リアルタイムOS、またはOS不使用）では、動的リンクのインフラ（ローダー、共有ライブラリ管理）が存在しないため、原則として静的リンクが使われます。

• ベアメタル/RTOS→ 静的リンク一択。リンカスクリプトで最終的なメモリ配置を完全制御する
• 組み込みLinux→ 動的リンク可能。buildroot等でクロスコンパイル用の共有ライブラリを構築する

# 動的リンクの依存関係を確認
ldd myapp

# 静的リンク気味かどうか（表示は distro / file により文言差あり）
file myapp

• 静的：自己完結しやすいが、サイズ増・更新は再リンク寄りになりがち
• 動的：環境側の .so と運用ポリシーが必要だが、アップデートや共有の自由度が増えることが多い
• 組み込みは 実行環境の前提 がデスクトップと違うので、そのまま当てはめない