What Is Dynamic Linking? Resolving Libraries at Load Time
Dynamic linking resolves a program references to shared libraries at load time or runtime, rather than copying that library code into the executable at build time.
When you build a program, library code can be included one of two ways. Static linking copies it into the binary. Dynamic linking leaves a reference that the operating system resolves when the program loads, pulling in a shared library (a .so, .dll, or .dylib) that many programs can use at once. This keeps binaries small but adds a runtime dependency.
How dynamic linking works
The linker records which shared libraries the program needs and which symbols it uses, but does not include their code. At load time, the dynamic loader finds those libraries on the system, maps them into memory, and wires up the references before execution begins.
Dynamic vs static linking
Static linking yields a larger, self-contained binary with no external library dependencies. Dynamic linking yields a smaller binary that shares libraries across programs and can pick up library updates without rebuilding, at the cost of needing those libraries present and compatible.
Benefits of dynamic linking
- Smaller executables, since library code is not duplicated.
- Shared memory for common libraries across many processes.
- Security and bug fixes in a library reach all programs at once.
- Optional plugins loaded on demand at runtime.
The downsides
Dynamic linking introduces the classic dependency problem: the program needs the right library version at runtime. A missing or mismatched shared library causes load-time failures (the dreaded "shared library not found"), and incompatible versions cause subtle breakage.
A quick example
On Linux, ldd ./app lists the shared libraries a program needs. If one is missing on the target machine, the program fails to start, even though it built fine.
Dynamic linking in CI
A build that works on one runner can fail on another if a shared library is missing or the wrong version, an environment mismatch, not a code bug. Latchkey provides consistent, reproducible runner environments so dynamic-linking dependencies resolve the same way every run, avoiding works-on-my-machine surprises.
Key takeaways
- Dynamic linking resolves shared-library references at load time, not at build time.
- It keeps binaries small and shares libraries, but adds a runtime dependency.
- Missing or mismatched shared libraries cause environment-specific, not code, failures.