World Library  
Flag as Inappropriate
Email this Article

Static linking

Article Id: WHEBN0003609751
Reproduction Date:

Title: Static linking  
Author: World Heritage Encyclopedia
Language: English
Subject: Dillo
Publisher: World Heritage Encyclopedia

Static linking

In computer science, a static library or statically-linked library is a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable.[1] This executable and the process of compiling it are both known as a static build of the program. Historically, libraries could only be static. Static libraries are either merged with other static libraries and object files during building/linking to form a single executable, or they may be loaded at run-time into the address space of the loaded executable at a static memory offset determined at compile-time/link-time.

Advantages and disadvantages

There are several advantages to statically linking libraries with an executable instead of dynamically linking them. The most significant is that the application can be certain that all its libraries are present and that they are the correct version. This avoids dependency problems, known colloquially as DLL Hell or more generally dependency hell. Usually, static linking will result in a significant performance improvement. Static linking can also allow the application to be contained in a single executable file, simplifying distribution and installation.

With static linking, it is enough to include those parts of the library that are directly and indirectly referenced by the target executable (or target library). With dynamic libraries, the entire library is loaded, as it is not known in advance which functions will be invoked by applications. Whether this advantage is significant in practice depends on the structure of the library.

In static linking, the size of the executable becomes greater than in dynamic linking, as the library code is stored within the executable rather than in separate files. But if library files are counted as part of the application then the total size will be similar. On Microsoft Windows it is common to include the library files an application needs with the application.[2] On Unix-like systems this is less common as package management systems can be used to ensure the correct library files are available. This allows the library files to be shared between many 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. In practice, many executables (especially those targeting Microsoft Windows) 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++ on Linux

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 a ".a" extension on UNIX[1] and ".lib" on Microsoft Windows.

For example, to create an archive from files class1.o, class2.o, class3.o, the following command would be used:[1]

ar rcs libclass.a class1.o class2.o class3.o

to compile a program that depends on class1.o, class2.o, and class3.o one could do:

cc main.c libclass.a

or (if libclass.a is placed in standard library path, like /usr/local/lib)

cc main.c -lclass

or (during linking)

ld ... main.o -lclass ...

instead of:

cc main.c class1.o class2.o class3.o

See also


Template:Application binary interface

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.