the toolchain

When you write a program, you type ordinary text into a file, for example a file called main.c. But your computer cannot run text. It can only run machine code: long strings of numbers that the processor knows how to execute. The toolchain is the chain of separate programs that, working in order, turn your text into those runnable numbers. Think of an assembly line in a factory: a raw part goes in at one end, each station does one job, and a finished product comes out the other end.

The classic stations, in order, are: the preprocessor (handles lines starting with #, like #include and #define, producing expanded text), the compiler (turns that text into assembly language for your kind of processor), the assembler (turns assembly into raw machine-code bytes packed into an object file), and the linker (stitches one or more object files plus libraries into a single executable file). Later, when you actually run the program, the loader copies the executable into memory and starts it. People say 'compile' loosely to mean this whole journey, but strictly each stage is a different tool with a different job.

Why care that it is several tools and not one? Because errors point at different stages and read very differently. A typo in your code is caught early by the compiler. A function you declared but never wrote is caught at the very end by the linker as an 'undefined reference'. A program that builds perfectly but cannot find a needed library file when launched fails in the loader. Knowing which station failed tells you where to look. When you run a single command like gcc -O2 -Wall main.c -o app, the gcc driver is quietly running all of these stages for you in sequence.