Static vs Dynamic Linking
That the choice is only about file size. It is mainly about when symbol resolution happens and who owns the upgrade: a statically linked program keeps whatever version it was built against forever, including the security bugs; a dynamically linked one gets whichever version the loader finds, including an incompatible one.
Static linking
When you want one file that runs anywhere the ABI matches, reproducible bytes, and no dependency on what is installed on the host.
Dynamic linking
When many programs share a library, when a library must be patched without rebuilding its users, or when the platform requires it for system libraries.
| Aspect | Static linking | Dynamic linking |
|---|---|---|
| When symbols are resolved | At build time, by the linker. | At load time or first call, by the dynamic loader. |
| Upgrading a dependency | Rebuild and redeploy every program that uses it. | Replace the shared object; every program picks it up on next start. |
| Failure mode | Unresolved symbol at build time — loud and early. | Missing or incompatible library at start-up, or at the first call into it. |
| Startup cost | None beyond loading the image. | Relocation processing and symbol lookup, unless prelinked or bound lazily. |
| Optimization across the boundary | Possible — LTO can see the library’s code. | Not possible; calls go through the procedure linkage table. |
| Duplication | Each program carries its own copy of the code it uses. | One copy of the text segment shared across processes. |