the loader

Compiling and linking produce a file on disk, but a file sitting on disk is not yet a running program. Something has to copy it into the computer's memory, set up the conditions it expects, and hand control to it so the processor starts executing its instructions. That something is the loader, a part of the operating system that springs into action the moment you type ./app or double-click an icon. It is the bridge between a dead file and a live process.

When you launch a program, the loader reads the executable's format, learns from it which parts go where, and creates a fresh address space for the new process. It maps the code section into memory as read-only and executable, maps the initialised data into writable memory, reserves zeroed space for the .bss variables, sets up the stack and the program's arguments and environment, and then jumps to the program's entry point to begin execution. On modern systems much of this is done lazily through virtual memory: pages of the file are pulled in only as they are actually touched, so a large program starts quickly without copying all of it up front.

The loader is also where a whole class of late, run-time-only failures lives, distinct from compile and link errors. If your program depends on a shared library that the loader cannot find at launch, you get an error like 'cannot open shared object file' even though the program compiled and linked perfectly. For programs that use dynamic libraries, a helper called the dynamic linker or run-time loader does extra work at startup, finding and mapping in those shared libraries and patching the last few addresses before main is reached.