The C Toolchain

A C program is not "interpreted." It goes through four well-defined stages to become something a CPU can run. Knowing what happens at each stage is the difference between a confused programmer staring at a "undefined reference to foo" error and one who instantly knows to add foo.c to the link command.

The four stages

In one clang hello.c -o hello command, the driver actually runs all four stages in sequence — but you can stop after any one of them.

Stage 1: the preprocessor

The preprocessor is a text engine. It runs before the compiler and handles every line that starts with #:

• #include <foo.h> — paste the contents of foo.h here.
• #define MAX 100 — replace every occurrence of MAX with 100.
• #ifdef DEBUG / #endif — keep or drop the enclosed lines.
• #pragma once — non-standard but widely supported include guard.

It does not understand C syntax. It is just a smart find-and- replace pass.

After preprocessing, SQUARE(n) literally becomes ((n) * (n)). The outer parentheses are not decorative — they prevent surprises when the macro is used in expressions like SQUARE(a + b).

Header files and include guards

A header file (.h) typically contains type declarations, function declarations (signatures, not bodies), and macros. It is shared between several .c files via #include.

Because #include is just text substitution, including the same header twice would re-declare everything and break the build. Two fixes exist:

1. Include guards — the classic #ifndef X / #define X / #endif.
2. #pragma once — a one-liner supported by every modern compiler.

// shapes.h
#ifndef SHAPES_H
#define SHAPES_H

double circle_area(double radius);

#endif

Stage 2: compilation

The compiler takes one translation unit (a .c plus everything it pulled in via #include) and produces assembly for the target CPU. This is where syntax errors, type errors, and most warnings come from.

The compiler also runs your optimizations: dead-code elimination, inlining, register allocation, loop unrolling, vectorization. Flags like -O0, -O1, -O2, -O3, and -Os (size) control how aggressively it does this.

Stage 3: assembly

The assembler is the simplest stage: it translates human-readable assembly into a binary object file (.o on Unix-like systems, .obj on Windows). Object files contain machine code plus symbols — names the linker can resolve.

Stage 4: linking

The linker stitches multiple object files together. It also pulls in standard libraries (libc for printf, libm for sqrt, etc.) and resolves undefined symbols — references that one object file makes to functions defined in another.

If you see:

undefined reference to `sqrt`

…it means the compiler found #include <math.h> (which declares sqrt) but the linker never got libm. The fix is -lm.

If you see:

undefined reference to `greet`

…it means you declared greet() in a header and called it from main.c, but never compiled or passed greet.c (or its .o) to the linker.

Multi-file builds in the browser sandbox

The browser sandbox supports multiple translation units. Pass files and entryFilename to <CodeBlock> and you can practice the same header / implementation split you would use in a real project.

Try deleting mathx.c from the file tree (you cannot in this widget, but imagine it) — you would get an "undefined reference to add" error from the linker, not the compiler. The compiler was happy with the declaration in mathx.h; the linker had nothing to point those calls at.

Static vs dynamic libraries

Two flavors of library exist on most systems:

• Static library (libfoo.a on Unix, foo.lib on Windows): the linker copies the needed object code into your binary. The resulting executable is self-contained but larger.
• Shared / dynamic library (libfoo.so, libfoo.dylib, foo.dll): the binary just records "I depend on libfoo"; the OS loads it at runtime and resolves the symbols. Smaller binaries; multiple programs share one copy in memory; but you must ship the library.

printf lives in libc, which is dynamic on virtually every desktop system. That is why a "hello world" binary is so small.

Common compiler flags worth knowing

Practice: split a program

Test your understanding