Editing Linker (computing) (section)

== Dynamic linking ==
{{See also|Dynamic linker}}

Many [[operating system]] environments allow dynamic linking, deferring the resolution of some undefined symbols until a program is run. That means that the executable code still contains undefined symbols, plus a list of objects or libraries that will provide definitions for these. Loading the program will load these objects/libraries as well, and perform a final linking.

This approach offers two advantages:

* Often-used libraries (for example the standard system libraries) need to be stored in only one location, not duplicated in every single executable file, thus saving limited [[computer memory|memory]] and [[disk storage|disk]] space.
* If a bug in a library function is corrected by replacing the library or [[Computer performance|performance]] is improved, all programs using it dynamically will benefit from the correction after restarting them. Programs that included this function by static linking would have to be re-linked first.

There are also disadvantages:

* Known on the [[Windows]] platform as "[[DLL hell]]", an incompatible updated library will break executables that depended on the behavior of the previous version of the library if the newer version is not correctly [[backward compatible]].
* A program, together with the libraries it uses, might be certified (e.g. as to correctness, documentation requirements, or performance) as a package, but not if components can be replaced (this also argues against automatic OS updates in critical systems; in both cases, the OS and libraries form part of a ''qualified'' environment).
[[Containerization (computing)|Contained]] or [[OS-level virtualization|virtual]] environments may further allow [[System administrator|system administrators]] to mitigate or trade-off these individual pros and cons.