static linking

A static library or statically linked library contains functions and data that can be included in a consuming computer program at build-time such that the library does not need to be accessible in a separate file at run-time. If all libraries are statically linked, then the resulting executable will be stand-alone, a.k.a. a static build.

A static library is either merged with other static libraries and object files at build-time to form a single executable or loaded at run-time into the address space of their corresponding executable at a static memory offset determined at compile-time/link-time.

Comparison to dynamic linking

Historically, all library linking was static, but today dynamic linking is an alternative and entails inherent trade-offs.

An advantage of static over dynamic is that the application is guaranteed to have the library routines it requires available at run-time, as the code to those routines is embedded in the executable file. With dynamic linking, not only might the library file be missing, but even if found, it could be an incompatible version. Static avoids DLL Hell or more generally dependency hell and therefore can simplify development, distribution and installation.

Another trade-off is memory used to load the library. With static linking, a smart linker only includes the code that is actually used, but for a dynamic library, the entire library is loaded into memory.

Another trade-off is that the size of the executable is larger with static linking than dynamic. But, if the size of an application is measured as the sum of the executable and its dynamic libraries, then overall size is generally less for static. Then again, if the same dynamic library is used by multiple applications, then overall size of the combined applications plus DLLs might be less with dynamic.

A common practice on Windows is to install a program's dynamic libraries with the program file. On Unix-like systems this is less common as package management systems can be used to ensure the correct library files are available in a shared, system location. This allows library files to be shared between applications leading to space savings. It also allows the library to be updated to fix bugs and security flaws without updating the applications that use the library. But shared, dynamic libraries leads to the risk of dependency problems.

In practice, many executables use both static and dynamic libraries.

Linking and loading

Any static library function can call a function or procedure in another static library. The linker and loader handle this the same way as for kinds of other object files. Static library files may be linked at run time by a linking loader (e.g., the X11 module loader). However, whether such a process can be called ''static linking'' is controversial.

Creating static libraries in C/C++

Static libraries can be easily created in C or in C++. These two languages provide storage-class specifiers for indicating external or internal linkage, in addition to providing other features. To create such a library, the exported functions/procedures and other objects variables must be specified for '' external linkage'' (i.e. by not using the C static keyword). Static library filenames usually have "" extension on Unix-like systems and "" extension on Microsoft Windows.

For example, on a Unix-like system, to create an archive named from files , , , the following command would be used:
ar rcs libclass.a class1.o class2.o class3.o
to compile a program that depends on , , and , one could do:
cc main.c libclass.a
or (if is placed in standard library path, like )
cc main.c -lclass
or (during linking)
ld ... main.o -lclass ...
instead of:
cc main.c class1.o class2.o class3.o

See also

* Static build
*Library (computing)
*Linker (computing)
* Loader (computing)
*Shared library
* Dynamic-link library (DLL, .dll)
* External variable
* Object file
* Prebinding
* JAR (file format)

References

{{Application binary interface

Computer libraries