Static v/s Dynamic Libraries

Static libraries

Historically, libraries could only be static. A static library, also known as an archive, consists of a set of routines which are copied into a target application by the compiler, linker, or binder, producing object files and a stand-alone executable file. This process, and the stand-alone executable file, are known as a static build of the target application. Actual address, references for jumps and other routine calls are stored in a relative address or symbolic which cannot be resolved until all code and libraries are assigned final static addresses.

The linker resolves all of the unresolved addresses into fixed or relocatable addresses (from a common base) by loading all code and libraries into actual runtime memory locations. This linking process can take as much, or more time than the compilation process, and must be performed when any of the modules is recompiled. Most compiled languages have a standard library (for example, the C standard library) but programmers can also create their own custom libraries. Commercial compiler publishers provide both standard and custom libraries with their compiler products.

A linker may work on specific types of object files, and thus require specific (compatible) types of libraries. Collecting object files into a static library may ease their distribution and use. A client, either a program or a library subroutine, accesses a library object by referencing just its name. The linking process resolves references by searching the libraries in the order given. Usually, it is not considered an error if a name can be found multiple times in a given set of libraries.

Dynamic linking

Dynamic linking means that the subroutines of a library are loaded into an application program at runtime, rather than being linked in at compile time, and remain as separate files on disk. Only a minimal amount of work is done at compile time by the linker; it only records what library routines the program needs and the index names or numbers of the routines in the library. The majority of the work of linking is done at the time the application is loaded (loadtime) or during execution (runtime). The necessary linking code, called a loader, is actually part of the underlying operating system. At the appropriate time the loader finds the relevant libraries on disk and adds the relevant data from the libraries to the process's memory space.

Some operating systems can only link in a library at loadtime, before the process starts executing; others may be able to wait until after the process has started to execute and link in the library just when it is actually referenced (i.e., during runtime). The latter is often called "delay loading". In either case, such a library is called a dynamically linked library.

The nature of dynamic linking makes it a common boundary in software licenses.

Plugins are one common usage of dynamically linked libraries, which is especially useful when the libraries can be replaced by other libraries with a similar interface, but different functionality. Software may be said to have a "plugin architecture" if it uses libraries for core functionality with the intention that they can be replaced. Note, however, that the use of dynamically linked libraries in an application's architecture does not necessarily mean that they may be replaced.

Dynamic linking was originally developed in the Multics operating system, starting in 1964. It was also a feature of MTS (the Michigan Terminal System), built in the late 1960s.^[1] In Microsoft Windows, dynamically-linked libraries are called dynamic-link libraries or "DLLs".

Naming

GNU/Linux, Solaris and other System V Release 4 derivatives, and BSD variants

libfoo.a and libfoo.so files are placed in directories like /lib, /usr/lib or /usr/local/lib. The filenames always start with lib, and end with .a (archive, static library) or .so (shared object, dynamically linked library), with an optional interface number. For example libfoo.so.2 is the second major interface revision of the dynamically linked library libfoo. Old Unix versions would use major and minor library revision numbers (libfoo.so.1.2) while contemporary Unixes will only use major revision numbers (libfoo.so.1). Dynamically loaded libraries are placed in /usr/libexec and similar directories. The .la files sometimes found in the library directories are libtool archives, not usable by the system as such.

Mac OS X and upwards

The system inherits static library conventions from BSD, with the library being in a .a file, and can use .so-style dynamically-linked libraries (with the .dylib suffix instead). Most libraries in Mac OS X, however, are "frameworks", placed inside of special directories called "bundles", which wrap the library's required files and metadata. For example a library called "My Neat Library" would be implemented in a bundle called "My Neat Library.framework".

Microsoft Windows

*.DLL files are dynamically linkable libraries. Other file name patterns may be used for specific purpose DLLs, e.g. *.OCX for OCX control libraries. The interface revisions are either encoded in the files, or abstracted away using COM-object interfaces. Depending on how they are compiled, *.LIB files can be either static libraries or representations of dynamically linkable libraries needed only during compilation, known as "Import Libraries". Unlike in the UNIX world, where different file extensions are used, when linking against .LIB file in Windows one must first know if it is a regular static library or an import library. In the latter case, a .DLL file must be present at runtime.