I am reading about libraries in C but I have not yet found an explanation on what an object file is. What's the real difference between any other compiled file and an object file?
I would be glad if someone could explain in human language.
-
A more active version of this: http://stackoverflow.com/questions/12122446/how-does-c-linking-work-in-practice – Ciro Santilli OurBigBook.com Nov 09 '15 at 11:02
-
Also see [Assembly code vs Machine code vs Object code?](https://stackoverflow.com/questions/466790/assembly-code-vs-machine-code-vs-object-code) – Rick Jan 09 '20 at 08:10
-
1object files aren't specific to C – JobHunter69 Jan 26 '21 at 16:14
-
@JobHunter69 what exactly do you mean?AFAIK,not every compiled language necessarily has object files.Object files are a common intermediate representation used by many compiled languages,but not all.Rust language generates "library crates" (.rlib files) instead of object files. These files contain compiled code,debug information, and other metadata, and are used by the Rust compiler and linker to build executable programs and libraries. Go generates object files in the ELF format, but they contain a different format of symbol information compared to object files generated by C compilers. – Guy Avraham Feb 26 '23 at 07:54
5 Answers
An object file is the real output from the compilation phase. It's mostly machine code, but has info that allows a linker to see what symbols are in it as well as symbols it requires in order to work. (For reference, "symbols" are basically names of global objects, functions, etc.)
A linker takes all these object files and combines them to form one executable (assuming that it can, i.e.: that there aren't any duplicate or undefined symbols). A lot of compilers will do this for you (read: they run the linker on their own) if you don't tell them to "just compile" using command-line options. (-c
is a common "just compile; don't link" option.)

- 3,482
- 3
- 38
- 50

- 84,970
- 20
- 145
- 172
-
Actually, with most compilers, the output from the compilation phase is assembly code, and the compiler then invokes the assembler to turn that into an object file. – Chris Dodd Jul 13 '13 at 05:04
-
23@ChrisDodd: That was often the case with older compilers. These days, a compiler won't generate assembly code unless you ask it to, and often doesn't use it internally. But either way, assembly would be a sub-phase of the compilation phase, so all that is moot. – cHao Jul 13 '13 at 13:43
-
2
-
2@Honey: Generally, no. Even if the object file were in a format designed for execution (which it basically never is), that part about "symbols it requires in order to work" basically kills the deal. Even your standard "hello world" requires linking against a C runtime library. – cHao Jul 20 '18 at 14:19
An Object file is the compiled file itself. There is no difference between the two.
An executable file is formed by linking the Object files.
Object file contains low level instructions which can be understood by the CPU. That is why it is also called machine code.
This low level machine code is the binary representation of the instructions which you can also write directly using assembly language and then process the assembly language code (represented in English) into machine language (represented in Hex) using an assembler.
Here's a typical high level flow for this process for code in High Level Language such as C
--> goes through pre-processor
--> to give optimized code, still in C
--> goes through compiler
--> to give assembly code
--> goes through an assembler
--> to give code in machine language which is stored in OBJECT FILES
--> goes through Linker
--> to get an executable file.
This flow can have some variations for example most compilers can directly generate the machine language code, without going through an assembler. Similarly, they can do the pre-processing for you. Still, it is nice to break up the constituents for a better understanding.

- 4,974
- 3
- 26
- 32
-
9The optimized code isn't being generated at pre-processor stage nor immediately after it. Pre-processor only deals with its own language and that's it. Optimization happens at compilation and assembly stages. – Ignas2526 Apr 05 '14 at 14:01
-
1Is the object file we get after compiling same as the executable file in machine language. I'm confused because, you said object file is created at second step from the last and last step is the executable file. So, the .0 file we get after compilation, is that the executable file? – AV94 Sep 08 '16 at 06:08
-
There are 3 kind of object files.
1. Relocatable object files:
Contain machine code in a form that can be combined with other relocatable object files at link time, in order to form an executable object file.
If you have an a.c
source file, to create its object file with GCC you should run:
gcc a.c -c
The full process would be:
- preprocessor (cpp) would run over
a.c
- Its output (still source; cpp) will feed into the compiler (
cc1
). - Its output (assembly) will feed into the assembler (
as
) - assembler (
as
) will produce the relocatable object file.
That relocatable object file contains:
- object code, and metadata for linking, and debugging (if
-g
was used) - it is not directly executable.
2. Shared object files:
Special type of relocatable object file that can be loaded dynamically, either at load time, or at run time.
- Shared libraries are an example of these kinds of objects.
3. Executable object files:
Contain machine code that can be directly loaded into memory (by the loader, e.g execve) and subsequently executed.
The result of running the linker over multiple relocatable object files is an executable object file. The linker merges all the input object files from the command line, from left-to-right, by merging all the same-type input sections (e.g. .data
) to the same-type output section. It uses symbol resolution and relocation.
Bonus read: Static vs Dynamic Libraries
When linking against a static library the functions that are referenced in the input objects are copied to the final executable. With dynamic libraries a symbol table is created instead that will enable a dynamic linking with the library's functions/globals. Thus, the result is a partially executable object file, as it depends on the library. If the library doesn't exist, the file can no longer execute.
The linking process can be done as follows:
ld a.o -o myexecutable
The command: gcc a.c -o myexecutable
will invoke all the commands mentioned at point 1 and at point 3 (cpp
-> cc1
-> as
-> ld
1)
1: actually is collect2
, which is a wrapper over ld
.

- 11,929
- 9
- 52
- 82
An object file is just what you get when you compile one (or several) source file(s).
It can be either a fully completed executable or library, or intermediate files.
The object files typically contain native code, linker information, debugging symbols and so forth.

- 202,337
- 40
- 393
- 406
Object files are codes that are dependent on functions, symbols, and text to run the program. Just like old telex machines, which required teletyping to send signals to other telex machine.
In the same way processor's require binary code to run, object files are like binary code but not linked. Linking creates additional files so that the user does not have to have compile the C language themselves. Users can directly open the exe file once the object file is linked with some compiler like c language , or vb etc.

- 1,202
- 16
- 28

- 21
- 1