a shared library

Think of a single reference dictionary chained to a desk in a busy library, consulted by everyone who walks up, instead of every visitor lugging around their own heavy copy. A shared library is that communal dictionary for code: a bundle of routines (functions) that many programs can use at once, loaded into memory once and shared, rather than copied into each program.

Concretely, a shared library is a file of compiled, reusable code — a .so file on Linux and macOS, a .dll on Windows — that programs link against dynamically. At launch, the loader maps the shared library into memory; multiple running programs can then use the same single in-memory copy of its code at the same time. This works because the library's code is position-independent (it runs correctly wherever it is mapped) and read-only code can be safely shared: the OS arranges for all the programs to see the same physical pages of library code, so the code exists in RAM just once even if a hundred programs are using it.

Why it matters: shared libraries save a lot of memory and disk by avoiding duplication, and they let you fix or upgrade a library once and have every program benefit. They are the practical home of dynamic linking. The catch is the dependency: a program needs the right shared libraries present and compatible at run time, so missing-library and version-conflict errors are the price of sharing. Note that only the read-only code is truly shared; each program still gets its own private copy of the library's writable data.