Co to jest format pliku O?
Plik .o to skompilowany plik obiektowy - pośredni plik binarny tworzony przez kompilator, taki jak GCC lub Clang, podczas tłumaczenia pojedynczego pliku źródłowego C na kod maszynowy. Wynik zawiera instrukcje maszynowe, zainicjowane i niezainicjowane segmenty danych, tablicę symboli oraz wpisy relokacji, ale nie jest jeszcze plikiem wykonywalnym: odwołania do funkcji i zmiennych zdefiniowanych w innych jednostkach translacji pozostają nierozstrzygniętymi symbolami zastępczymi dla linkera.
Format binarny zależy od platformy docelowej:
- W systemie Linux i większości systemów Unix/BSD pliki
.oużywają kontenera ELF (Executable and Linkable Format), rozpoznawanego po magicznych bajtach\x7FELFna offsecie 0 oraz polue_typeo wartościET_REL(relokowalny, wartość0x0001). - W systemie macOS odpowiednik używa formatu Mach-O, zaczynającego się od
CF FA ED FE(64-bit little-endian). - W systemie Windows funkcjonalnie identyczny plik posiada rozszerzenie .obj i korzysta z formatu COFF.
Po kompilacji linker (ld) łączy jeden lub więcej plików .o z bibliotekami, aby utworzyć plik wykonywalny lub bibliotekę współdzieloną. Wiele plików .o można również połączyć w archiwum statyczne za pomocą polecenia ar.
Pliki .o są tymczasowymi artefaktami budowania generowanymi automatycznie przez łańcuch narzędzi i nie są przeznaczone do otwierania przez użytkowników końcowych. Programiści, którzy muszą je sprawdzić, mogą użyć narzędzi nm, objdump lub readelf do zbadania symboli, sekcji i deasemblacji.
Bezpieczeństwo
RYZYKO: LOWPlik .o to dane z czasu budowania, a nie coś, co system operacyjny uruchamia, więc stanowi niewielkie bezpośrednie ryzyko dla użytkowników końcowych - nie można go kliknąć dwukrotnie i uruchomić. Dla programistów kwestią jest zaufanie do łańcucha dostaw: linkowanie obiektu z niezaufanego źródła „wszywa” jego kod maszynowy bezpośrednio do programu, więc należy budować tylko z obiektów/bibliotek z zaufanych źródeł. Obiekty we własnym drzewie budowania są bezpieczne do usunięcia; zostaną wygenerowane ponownie przy następnej kompilacji.
Szczegóły formatu
w pigułcePEŁNA NAZWACompiled Object Fileznany również jako object file, object code
DEWELOPERUnix lineage; ELF defined by System V ABI / Tool Interface Standard, COFF/Mach-O by Microsoft/Apple. No single vendor.od Object-file concept from early Unix (1970s); ELF since System V Release 4 (early 1990s)
KATEGORIAPliki developerskie
TYP MIMEapplication/x-object
TYPSkompilowany relokowalny plik obiektowy (kod maszynowy + symbole, jeszcze nielinkowany)
STANDARDOtwarty · bezpłatny
MAGICZNE BAJTY · SYGNATURA PLIKU
OFFSET
00010203
HEX
7F454C46
ASCII
·ELF
Rozszerzenie .o określa rolę, a nie pojedynczy format bajtowy. W systemach Linux/Unix .o to obiekt ELF zaczynający się od 7F 45 4C 46 („\x7FELF”) z e_type = ET_REL (0x0001, relokowalny). W macOS .o to Mach-O, zaczynający się od CF FA ED FE (64-bit LE) lub FE ED FA CF (big-endian). Obiekty Windows COFF .obj nie mają stałego początkowego ciągu magicznego (pole maszyny, np. 64 86 dla x86-64, znajduje się blisko początku). Identyfikuj po kontenerze obiektów danej platformy, a nie po jednej uniwersalnej sygnaturze.
Programy otwierające pliki O
Windows2 apps
Microsoft Visual Studio
Freemium MSVC używa formatu COFF .obj, a nie Unixowego .o. Unixowy .o można zbudować w Windows tylko przez WSL/MinGW z pasującym łańcuchem narzędzi - nie jest to natywny format dla tego środowiska. 
MinGW-w64 / WSL (gcc, binutils)
Open-source Dostarcza gcc/clang + binutils dla Windows, umożliwiając linkowanie i inspekcję plików .o w stylu Unixowym. 
macOS2 apps
Apple Xcode / Clang
Darmowy Clang w Xcode buduje i linkuje pliki .o w formacie Mach-O. Można je badać za pomocą „nm”/„otool -tv plik.o” (instalacja przez „xcode-select --install”).
GCC (Homebrew)
Open-source Alternatywny kompilator do budowania/linkowania plików .o; generuje obiekty Mach-O w systemie macOS. 
Linux3 apps
GCC / Clang (linker)
Open-source Pliku .o się nie otwiera - linkuje się go: „gcc a.o b.o -o app” tworzy plik wykonywalny. Kompilacja pojedynczego obiektu odbywa się przez „gcc -c plik.c”.
binutils (nm / objdump / readelf)
Open-source „nm plik.o” listuje symbole; „objdump -d plik.o” deasembluje; „readelf -a plik.o” pokazuje pełną strukturę ELF.
Ghidra
Open-source Zaimportuj .o w celu pełnej deasemblacji/dekompilacji podczas inżynierii wstecznej skompilowanego kodu. Szczegóły techniczne
specyfikacja| Format kontenera | ELF w Linux/Unix, Mach-O w macOS, COFF w Windows (gdzie plik zazwyczaj ma rozszerzenie `.obj`) |
| Kodowanie pliku | Binarne (nieczytelne dla człowieka tekstowo) |
| Magiczne bajty ELF | `7F 45 4C 46` (`\x7FELF`) na offsecie 0 - obecne we wszystkich plikach obiektowych opartych na ELF |
| Pole typu obiektu ELF | `e_type = ET_REL` (0x0001) w nagłówku ELF - odróżnia obiekt relokowalny od pliku wykonywalnego (`ET_EXEC`) lub biblioteki współdzielonej (`ET_DYN`) |
| Typ MIME | `application/x-object`; również przesyłany jako `application/octet-stream` przez serwery ogólnego przeznaczenia |
| Kolejność bajtów | Zakodowana w bajcie `EI_DATA` nagłówka ELF: little-endian (`ELFDATA2LSB`) na x86/x86-64/ARM, big-endian (`ELFDATA2MSB`) na PowerPC/SPARC |
| Kluczowe sekcje | `.text` (kod wykonywalny), `.data` (zainicjowane zmienne globalne), `.bss` (zmienne globalne inicjowane zerami), `.rodata` (stałe tylko do odczytu) |
| Tablica symboli | Sekcja `.symtab` listuje nazwę każdego zdefiniowanego i przywoływanego symbolu, jego powiązanie (lokalne/globalne/słabe), typ (funkcja/obiekt) oraz wartość |
| Wpisy relokacji | Sekcje `.rel.text` / `.rela.text` rejestrują każde miejsce adresowe, które linker musi „załatać” podczas łączenia plików obiektowych w końcowy plik binarny |
| Identyfikacja architektury | Pole `e_machine` w nagłówku ELF identyfikuje docelowy procesor: `EM_X86_64` (0x3E), `EM_AARCH64` (0xB7), `EM_386` (0x03) itd. |
| Typowy rozmiar pliku | Od 1 KB do kilku MB na jednostkę translacji, zależnie od złożoności źródła i poziomu optymalizacji kompilatora |
| Kompresja | Brak - pliki obiektowe są przechowywane jako surowe, nieskompresowane dane binarne |
| Model kompilacji jeden-do-jednego | Dokładnie jeden plik `.o` jest generowany na każdą jednostkę translacji źródła (jeden na plik `.c` lub `.cpp`); linker łączy je później |
| Pakowanie bibliotek statycznych | Wiele plików `.o` jest archiwizowanych w bibliotece statycznej `.a` za pomocą `ar`, co zachowuje każdy obiekt jako nazwany element składowy |
| Rozstrzyganie tylko w czasie linkowania | W przeciwieństwie do bibliotek współdzielonych `.so` / `.dylib`, wszystkie odwołania do symboli w `.o` są rozstrzygane całkowicie w czasie linkowania, nie pozostawiając dynamicznych zależności w czasie wykonywania |
| Narzędzia inspekcji | `nm` (lista symboli), `objdump` (deasemblacja i zrzuty sekcji), `readelf` (nagłówek ELF i szczegóły sekcji), `otool` (odpowiednik dla macOS Mach-O) |
| Wydano | Object-file concept from early Unix (1970s); ELF since System V Release 4 (early 1990s) |
| Najnowsza wersja | ELF format frozen since the 1990s; container evolves with each compiler/ABI |
| Otwarty standard | Tak · bezpłatny (royalty-free) |
| Specyfikacja | refspecs.linuxfoundation.org |
Konwersje O
Możliwa
.O .EXEPRZEWODNIK
Tak - skonsoliduj swoje pliki .o za pomocą GCC lub Clang używając jednej komendy: gcc *.o -o app
Jak konwertować
.O .APRZEWODNIK
Tak, możesz połączyć pliki .o w bibliotekę statyczną .a za pomocą jednego polecenia ar - nie zachodzi żadna…
Jak konwertować
.O .SOPRZEWODNIK
Możesz wygenerować .so z plików .o poprzez linkowanie za pomocą GCC lub Clang, ale tylko jeśli obiekty…
Jak konwertować
Niemożliwa
Pytania i odpowiedzi społeczności
pytania użytkownikówBrak pytań - bądź pierwszą osobą, która zapyta o pliki O.
Najczęściej zadawane pytania
Co to jest plik .o?
To skompilowany plik obiektowy - wyjściowy kod maszynowy, który kompilator generuje dla jednego pliku źródłowego przed linkowaniem. Linker łączy kilka plików .o (plus biblioteki) w gotowy program lub bibliotekę. W systemie Windows tę samą rolę pełni rozszerzenie .obj.
Jak otworzyć plik .o?
Nie otwiera się go jak dokumentu - jest on używany przez linker podczas budowania programu. Aby go zbadać, uruchom „nm plik.o” (symbole), „objdump -d plik.o” (deasemblacja) lub „readelf -a plik.o” (szczegóły ELF) w systemie Linux/macOS.
Czy mogę usunąć pliki .o?
Tak - pliki obiektowe to pośrednie artefakty budowania. Ich usunięcie (lub uruchomienie „make clean”) oznacza po prostu, że kompilator wygeneruje je ponownie przy następnym budowaniu. Nie usuwaj ich w trakcie trwania procesu kompilacji.
Jaka jest różnica między .o, .a i .so?
.o to pojedynczy skompilowany obiekt. .a to biblioteka statyczna - archiwum plików .o kopiowanych do programu w czasie linkowania. .so to biblioteka współdzielona ładowana w czasie wykonywania. Wszystkie trzy są budowane z tych samych obiektów.
Czy .o to samo co Windowsowy .obj?
Pełnią tę samą rolę (skompilowany obiekt), ale mają inne kontenery: Unixowy .o to ELF/Mach-O, Windowsowy .obj to COFF. Nie są one wymienne - należy skompilować kod źródłowy dla platformy docelowej.
Dlaczego otrzymuję błąd „undefined reference” podczas linkowania plików .o?
Symbol (funkcja/zmienna), którego używa Twój obiekt, nie jest zdefiniowany w żadnym pliku .o ani w bibliotece, którą linkujesz. Dodaj brakujący obiekt/bibliotekę do polecenia linkowania lub zdefiniuj symbol. „multiple definition” to błąd przeciwny - ten sam symbol występuje w dwóch obiektach.
Źródła
1GNU Binutils - nm/objdump/readelf documentationwww.gnu.org
2Wikipedia - Object fileen.wikipedia.org
