O ファイル形式とは？
.o ファイルはコンパイル済みオブジェクトファイルです。これは、GCCやClangなどのコンパイラが単一の Cソースファイル をマシンコードに翻訳する際に生成される中間バイナリです。出力にはマシン命令、初期化済みおよび未初期化のデータセグメント、シンボルテーブル、再配置エントリが含まれますが、まだ実行可能ではありません。他の翻訳単位で定義されている関数や変数への参照は、リンカーのための未解決のプレースホルダーとして残されています。
バイナリ形式はターゲットプラットフォームによって異なります：
- LinuxおよびほとんどのUnix/BSDシステムでは、
.oファイルはELF（Executable and Linkable Format）コンテナを使用します。これはバイトオフセット0にあるマジックバイト\x7FELFと、e_typeがET_REL（再配置可能、値0x0001）であることで識別されます。 - macOSでは、同等のファイルにMach-O形式が使用され、
CF FA ED FE（64ビットリトルエンディアン）で始まります。 - Windowsでは、機能的に同一のファイルには .obj 拡張子が付けられ、COFF形式が使用されます。
コンパイル後、リンカー（ld）が1つ以上の .o ファイルをライブラリと組み合わせて、実行ファイルまたは 共有ライブラリ を生成します。また、ar コマンドを使用して、複数の .o ファイルを1つの 静的アーカイブ にまとめることもできます。
.o ファイルはツールチェーンによって自動生成される一時的なビルド成果物であり、エンドユーザーが直接開くことを想定したものではありません。内容を検査する必要がある開発者は、nm、objdump、または readelf を使用して、シンボル、セクション、および逆アセンブリを確認できます。
セキュリティと安全性
リスク： LOW.oファイルはビルド時のデータであり、OSが起動するものではないため、エンドユーザーに対する直接的なリスクはほとんどありません（ダブルクリックして実行することはできません）。開発者にとっての懸念はサプライチェーンの信頼性です。信頼できないソースからのオブジェクトをリンクすると、そのマシンコードがプログラムに直接組み込まれるため、信頼できるソースのオブジェクト/ライブラリのみを使用してビルドしてください。自身のビルドツリー内のオブジェクトは削除しても安全であり、次回のコンパイル時に再生成されます。
形式の詳細
概要正式名称Compiled Object File別名 object file, object code
開発元Unix lineage; ELF defined by System V ABI / Tool Interface Standard, COFF/Mach-O by Microsoft/Apple. No single vendor.登場時期 Object-file concept from early Unix (1970s); ELF since System V Release 4 (early 1990s)
カテゴリ開発用ファイル
MIME タイプapplication/x-object
タイプコンパイル済み再配置可能オブジェクトファイル（マシンコード + シンボル、未リンク）
標準規格オープン・ロイヤリティフリー
マジックバイト ・ ファイルシグネチャ
オフセット
00010203
16進数
7F454C46
ASCII
·ELF
.o拡張子は役割を示すものであり、単一のバイト形式ではありません。Linux/Unixでは、.oは 7F 45 4C 46（«\x7FELF»）で始まり e_type = ET_REL（0x0001、再配置可能）を持つELFオブジェクトです。macOSでは、.oはMach-Oであり、CF FA ED FE（64ビットLE）または FE ED FA CF（ビッグエンディアン）で始まります。WindowsのCOFF .objオブジェクトには固定の先頭マジックはありません（開始付近に 64 86（x86-64用）などのマシンフィールドがあります）。単一の共通シグネチャではなく、プラットフォームのオブジェクトコンテナによって識別してください。
O ファイルを開くプログラム
Windows2 apps
Microsoft Visual Studio
フリーミアム MSVCはUnixの.oではなく、COFF形式の .obj を使用します。Unixの.oは、WSLやMinGWなどの対応するツールチェーンを介してのみWindows上でビルド可能であり、ネイティブで開くことはできません。 
MinGW-w64 / WSL (gcc, binutils)
オープンソース Windows上でgcc/clangとbinutilsを提供し、Unixスタイルの .o ファイルをリンクしたり検査したりできるようにします。 
macOS2 apps
Apple Xcode / Clang
無料 XcodeのclangはMach-O形式の .o ファイルをビルドおよびリンクします。「nm」や「otool -tv file.o」で検査できます（「xcode-select --install」でインストール可能）。 
Linux3 apps
GCC / Clang (linker)
オープンソース .oを開くのではなく、リンクします。「gcc a.o b.o -o app」とすると実行ファイルが生成されます。単一のオブジェクトをコンパイルするには「gcc -c file.c」を使用します。
binutils (nm / objdump / readelf)
オープンソース 「nm file.o」はシンボルをリストし、「objdump -d file.o」は逆アセンブルし、「readelf -a file.o」は完全なELF構造を表示します。 技術的詳細
詳細仕様| コンテナ形式 | Linux/UnixではELF、macOSではMach-O、WindowsではCOFF（通常 `.obj` という名前） |
| ファイルエンコーディング | バイナリ（人間が読めるテキストではない） |
| ELFマジックバイト | バイトオフセット0にある `7F 45 4C 46` (`\x7FELF`) - すべてのELFベースのオブジェクトファイルに存在 |
| ELFオブジェクトタイプフィールド | ELFヘッダー内の `e_type = ET_REL` (0x0001) - 再配置可能オブジェクトを実行ファイル (`ET_EXEC`) や共有ライブラリ (`ET_DYN`) と区別 |
| MIMEタイプ | `application/x-object`。一般的なサーバーでは `application/octet-stream` として扱われることもある |
| バイト順（エンディアン） | ELFヘッダーの `EI_DATA` バイトでエンコード：x86/x86-64/ARMではリトルエンディアン (`ELFDATA2LSB`)、PowerPC/SPARCではビッグエンディアン (`ELFDATA2MSB`) |
| 主要なセクション | `.text`（実行コード）、`.data`（初期化済みグローバル変数）、`.bss`（ゼロ初期化されたグローバル変数）、`.rodata`（読み取り専用定数） |
| シンボルテーブル | `.symtab` セクション。定義および参照されている各シンボルの名前、バインディング（ローカル/グローバル/ウィーク）、タイプ（関数/オブジェクト）、および値をリスト |
| 再配置エントリ | `.rel.text` / `.rela.text` セクション。オブジェクトファイルを最終的なバイナリにマージする際に、リンカーが修正（パッチ）する必要があるすべてのアドレススロットを記録 |
| アーキテクチャ識別 | ELFヘッダーの `e_machine` フィールドがターゲットCPUを識別：`EM_X86_64` (0x3E)、`EM_AARCH64` (0xB7)、`EM_386` (0x03) など |
| 一般的なファイルサイズ | ソースの複雑さとコンパイラの最適化レベルに応じて、1翻訳単位あたり1 KBから数MB |
| 圧縮 | なし - オブジェクトファイルは生の未圧縮バイナリデータとして保存される |
| 1対1コンパイルモデル | ソース翻訳単位（`.c` または `.cpp` ファイル1つ）ごとに正確に1つの `.o` ファイルが出力され、後にリンカーがそれらをマージする |
| 静的ライブラリのパッケージング | 複数の `.o` ファイルは `ar` を使用して `.a` 静的ライブラリにアーカイブされ、各オブジェクトは名前付きメンバーとして保持される |
| リンク時解決のみ | `.so` / `.dylib` 共有ライブラリとは異なり、`.o` 内のすべてのシンボル参照はリンク時に完全に解決され、実行時の動的依存関係は残らない |
| 検査ツール | `nm`（シンボルリスト）、`objdump`（逆アセンブリとセクションダンプ）、`readelf`（ELFヘッダーとセクションの詳細）、`otool`（macOSのMach-O用） |
| リリース日 | Object-file concept from early Unix (1970s); ELF since System V Release 4 (early 1990s) |
| 最新バージョン | ELF format frozen since the 1990s; container evolves with each compiler/ABI |
| オープンスタンダード | はい · ロイヤリティフリー |
| 仕様書 | refspecs.linuxfoundation.org |
O の変換
可能
コミュニティ Q&A
ユーザーからの質問まだ質問はありません。O ファイルについて最初の質問をしてみましょう。
よくある質問
.oファイルとは何ですか？
コンパイル済みのオブジェクトファイルです。リンカーによる結合前に、コンパイラが1つのソースファイルから生成するマシンコード出力です。リンカーが複数の.oファイル（およびライブラリ）を組み合わせて、最終的な実行ファイルやライブラリを作成します。Windowsでは、同じ役割に .obj 拡張子が使用されます。
.oファイルを開くにはどうすればよいですか？
ドキュメントのように開くものではありません。ビルド中にリンカーによって読み込まれます。内容を検査するには、Linux/macOSで「nm file.o」（シンボル）、「objdump -d file.o」（逆アセンブリ）、または「readelf -a file.o」（ELFの詳細）を実行します。
.oファイルを削除しても大丈夫ですか？
はい。オブジェクトファイルは中間ビルド成果物です。これらを削除する（または「make clean」を実行する）と、次回のビルド時にコンパイラが再生成します。ビルドの途中で削除しないでください。
.o、.a、.soの違いは何ですか？
.oは単一のコンパイル済みオブジェクトです。.aは静的ライブラリであり、リンク時にプログラムにコピーされる.oファイルのアーカイブです。.soは実行時にロードされる共有ライブラリです。3つとも同じオブジェクトから構築されます。
.oはWindowsの.objと同じですか？
役割（コンパイル済みオブジェクト）は同じですが、コンテナが異なります。Unixの.oはELF/Mach-Oであり、Windowsの.objはCOFFです。これらに互換性はありません。ターゲットプラットフォームに合わせてソースを再コンパイルする必要があります。
.oファイルのリンク時に「undefined reference」エラーが出るのはなぜですか？
オブジェクトが使用しているシンボル（関数や変数）が、リンクしているどの.oファイルやライブラリでも定義されていません。不足しているオブジェクトやライブラリをリンクコマンドに追加するか、シンボルを定義してください。「multiple definition」はその逆で、同じシンボルが2つのオブジェクトに存在する場合に発生します。
参考文献
1GNU Binutils - nm/objdump/readelf documentationwww.gnu.org
2Wikipedia - Object fileen.wikipedia.org
