With static linking, the linker includes the required code in the executable and fixes up calls to the functions' addresses. Dynamic linking works differently because the function remains in a shared library. How is that library mapped into a process's virtual address space, and how does the dynamic linker locate and connect calls to the external functions? I'm especially interested in how this works in practice on systems such as Linux.
4 Answers
The exact mechanisms differ between formats and operating systems—for example, ELF on Linux versus Windows PE/DLL files—but the general model is similar: map the library into the process, find exported symbols, apply relocations, and route imported calls through address tables or stubs.
A shared library contains a dynamic symbol table describing its exported functions and variables, along with offsets or relocation information. Once the loader knows where the library was mapped, it combines that base address with the symbol's offset to calculate the function's actual address.
On Linux, the dynamic loader (usually ld.so) runs before the program's main entry point. It finds the shared libraries listed in the executable, maps their segments into the process's virtual address space, and initializes them. Address-space layout randomization usually changes the libraries' base addresses each time the program runs.
Most modern position-independent code uses the PLT and GOT. A call to an imported function typically goes through a stub in the Procedure Linkage Table, which reads the target address from the Global Offset Table. With lazy binding, the first call invokes the dynamic linker, which resolves the symbol and writes the result into the GOT; later calls go directly to the resolved address. The loader may also resolve everything at startup instead.
Older or non-position-independent code could require patching instructions in the executable itself. That can make code pages private through copy-on-write, while the GOT-based approach lets the executable and library's code pages remain shared between processes.
The loader is sometimes called the runtime linker or link-loader. The static linker leaves relocation information and stubs behind, and the runtime component resolves them after the process has been loaded.