Static Linking

A static library — .a on Unix, .lib on Windows — is not a library in any meaningful sense. It is an archive: a container holding object files, with an index mapping symbol names to the member that defines them. ar creates it and nm reads it, and it has no code of its own.

The linker treats an archive differently from an object file, and this is the source of most static-linking confusion. An object file on the command line is always included. An archive is *searched*: when the linker reaches it, it looks for members defining symbols that are currently undefined, includes those, and moves on. Members defining nothing currently needed are skipped, permanently.

"Permanently" is the operative word. If an archive appears before the object that needs it, nothing is pending when it is scanned, so nothing is taken, and the later reference has no definition. This is why gcc -lm main.o fails where gcc main.o -lm succeeds, and it is a rule that surprises everyone exactly once. Circular dependencies between archives need --start-group/--end-group or a repeated mention, because a single pass cannot resolve them.

This also explains why static linking is granular. Only the members that were actually needed are included, so linking against a large archive does not embed the whole thing — a fact that makes the size argument against static linking much weaker than it first appears.

A statically linked binary has no runtime dependencies to satisfy. It runs on a machine with no matching libc version, in a container built FROM scratch, on a rescue system, or on a machine you have never seen. There is no libfoo.so.6: cannot open shared object file and no GLIBC_2.34 not found, because there is nothing to find.

It is also faster to start and marginally faster to run. No symbol resolution at load, no relocations for the loader to apply, no PLT indirection on cross-module calls, and — the more significant effect — every call is a direct call the optimizer can see through, so cross-library inlining becomes possible and [[link-time-optimization]] can operate across what were library boundaries. For short-lived processes the start-up difference alone can dominate.

And it is deterministic. The program you tested is the program that runs, byte for byte, with no possibility that the deployment environment supplies a different implementation of anything. That is a substantial reliability argument and it is why Go chose static linking by default and why a large fraction of container images ship static binaries.

The size cost is real and usually overstated. Because archives are extracted on demand, a static binary contains what it uses rather than the whole library, and --gc-sections prunes further. A static Go binary is a few megabytes; a statically linked C program using a handful of libc functions is often smaller than the dynamic version once you count the shared objects it would otherwise require. The size argument is much weaker than folklore holds.

The cost that actually matters is upgrade coupling. When a vulnerability is found in a compression library, a dynamically linked system replaces one file and every program on it is fixed at next start. A statically linked fleet must rebuild and redeploy every binary that contains a copy — which requires knowing which binaries those are, which requires a bill of materials, which many organisations do not have. This is not a hypothetical: it is the operational shape of every widely-used-library vulnerability, and it is the single strongest argument distributions make against static linking.

There are two further costs worth naming. Plugins are impossible — a statically linked program cannot load code later, which rules out an entire architectural style. And on glibc specifically, static linking is only partly supported: getaddrinfo and NSS load shared modules at runtime regardless, so a "static" glibc binary can still fail on a machine with different NSS libraries. musl has no such caveat, which is why static Linux binaries are usually built against musl.

The practical consensus has moved and it is worth stating rather than relitigating. Operating system components link dynamically, because a distribution needs to patch one file and fix everything, and because the OS is the one place where many processes genuinely run the same code and the memory sharing is worth real money.

Applications deployed as containers increasingly link statically, because the container already froze the dependency set — the sharing argument does not apply when every container has its own filesystem, and the patching argument is answered by rebuilding the image, which the pipeline does anyway. Go and Rust default to statically linking everything except libc for exactly this reason.

The interesting middle case is partial static linking: dynamic libc, static everything else. It keeps the one library the platform genuinely owns and patches, and removes version skew for the dependencies you control. -static-libstdc++ and -static-libgcc are the common instances, and Rust's default on Linux is precisely this shape.