library versioning and ABI compatibility

When a shared library is updated on your system, every program that uses it suddenly gets the new version next time it runs — without being recompiled. For that to be safe, the new library must still fit the programs built against the old one. Library versioning is the system of labels and rules that lets a library evolve while clearly signaling whether old programs can keep using it; ABI compatibility is the specific question of whether the binary interface stayed the same.

The ABI (Application Binary Interface) is the low-level contract between a compiled program and a compiled library: the exact layout of structures, the sizes of types, how arguments are passed, the precise names and signatures of functions. If a library update keeps the ABI the same — only fixing bugs or adding new functions without changing existing ones — old programs work unchanged; this is a backward-compatible change. If it changes the ABI — reordering a struct's fields, removing a function, changing a parameter — old programs may crash or misbehave when they load it. Libraries signal this with version numbers (often a scheme like major.minor.patch and an embedded soname): bumping the major version announces 'the ABI broke; do not assume old programs still work', while minor and patch bumps promise compatibility.

Why it matters: ABI compatibility is the quiet machinery that lets a system update a shared library to fix a security hole and have all your programs benefit without rebuilding. It is also a frequent source of pain: install a library whose ABI changed but whose version was not bumped correctly, and previously working programs start crashing in confusing ways. This is distinct from the API (the source-level interface): code can stay API-compatible — it still compiles — while breaking ABI, so that recompiling fixes it but merely swapping the library file does not.