Library (computing): Difference between revisions

Revision as of 13:05, 5 November 2004

Latest revision as of 01:09, 10 August 2025

Line 1:

{{short description|Collection of resources used to develop a computer program}}

In [[computer science]], a '''library''' is a collection of [[subprogram]]s used to develop [[software]]. Libraries are distinguished from [[executable]]s in that they are not independent [[Computer program|program]]s; rather, they are "helper" code that provides services to some other independent program.

{{redirect-distinguish|Software library|library software}}

{{About|a software development concept|a repository of digital assets|Digital library}}

{{Use dmy dates|date=February 2020|cs1-dates=y}}

[[Image:Ogg vorbis libs and application dia.svg|thumb|277px|right|Illustration of an application which uses libvorbisfile to play an [[Ogg Vorbis]] file]]

In [[computing]], a '''library''' is a collection of [[System resource|resources]] that can be used during [[software development]] to implement a [[computer program]]. Commonly, a library consists of [[executable]] code such as [[compiled]] [[function (computer science)|functions]] and [[Class (computer programming)|classes]], or a library can be a collection of [[source code]]. A resource library may contain data such as [[image]]s and [[Text string|text]].

Well-known libraries include:

* [[LINPACK]] for solving linear matrix problems

* [[C standard library]], whose implementations include [[glibc]]

* The [[Standard Template Library]] for [[C Plus Plus|C++]]

* Graphic libraries such as [[DirectX]] and [[OpenGL]]

A library can be used by multiple, independent consumers (programs and other libraries). This differs from resources defined in a program which can usually only be used by that program. When a consumer uses a library resource, it gains the value of the library without having to implement it itself. Libraries encourage [[software reuse]] in a [[Modular programming|modular]] fashion. Libraries can use other libraries resulting in a hierarchy of libraries in a program.

'''Library linking''' describes the inclusion of one or more of these software libraries into a new program. There are multiple types of linking: static linking and dynamic linking. These are described below.

When writing code that uses a library, a [[programmer]] only needs to know how to use it, its [[application programming interface]] (API) {{endash}} not its internal details. For example, a program could use a library that [[Abstraction (computer science)|abstracts]] a complicated [[system call]] so that the programmer can use the system feature without spending time to learn the intricacies of the system function.

== Static linking ==

'''Static linking''' is linking in which a library is embedded into the program executable at [[compile time]] by a [[linker]]. A linker is a separate utility which takes one or more libraries and [[object file]]s (which are previously generated by a compiler or an assembler) and produces an actual [[executable file]].

== History ==

One of the biggest disadvantages of static linking is that each executable ends up containing its own copy of the library. When many statically linked programs using the same library are simultaneously executed on the same machine, a great deal of memory can be wasted, as each execution loads its own copy of the library's data into memory.

The idea of a computer library dates back to the first computers created by [[Charles Babbage]]. An 1888 paper on his [[Analytical Engine]] suggested that computer operations could be punched on separate cards from numerical input. If these operation punch cards were saved for reuse then "by degrees the engine would have a library of its own."<ref>{{cite journal |url=https://www.fourmilab.ch/babbage/hpb.html |first=H. P. |last=Babbage |journal=Proceedings of the British Association |date=September 12, 1888 |___location=Bath|title=The Analytical Engine }}</ref>

Examples of libraries which are traditionally designed to be statically linked include the [[ANSI C standard library]] and the [[ALIB assembler library]]. Static linked libraries predate Fortran; Fortran's I/O was designed to use a preexisting package of I/O routines.

[[File:FirstCodeLibrary-ESDAC-ThePreparationOfProgramsForAnElectronicDigitalComputer-1951.jpg|thumb|A woman working next to a filing cabinet containing the subroutine library on reels of punched tape for the EDSAC computer.]]

== Dynamic linking ==

'''Dynamic linking''' is linking in which a library is loaded by the [[operating system]]'s [[Loader (computing)|loader]] separately from the executable file at [[loadtime]] or [[runtime]].

In 1947 [[Herman Goldstine|Goldstine]] and [[John von Neumann|von Neumann]] speculated that it would be useful to create a "library" of [[subroutine]]s for their work on the [[IAS machine]], an early computer that was not yet operational at that time.<ref>{{Cite book |last=Goldstine |first=Herman H. |url=http://dx.doi.org/10.1515/9781400820139 |title=The Computer from Pascal to von Neumann |date=2008-12-31 |publisher=Princeton University Press |isbn=978-1-4008-2013-9 |___location=Princeton |doi=10.1515/9781400820139}}</ref> They envisioned a physical library of [[magnetic wire recording]]s, with each wire storing reusable computer code.<ref>{{cite report |title=Planning and coding of problems for an electronic computing instrument |last1=Goldstine |first1=Herman |author-link1=Herman Goldstine |last2=von Neumann |first2=John |author-link2=John von Neumann |date=1947 |publisher=Institute for Advanced Study |pages=3, 21–22 |oclc=26239859 |quote=it will probably be very important to develop an extensive "library" of subroutines}}</ref>

Most operating systems resolve external dependencies like libraries (called ''imports'') as part of the loading process.

For these systems, the executables contain a table called an ''import directory'' which is a variable-length array of imports.

Each element in the array contains a name of a library.

The loader searches the hard disk for the needed library, loads it into memory at an unpredictable ___location and updates the executable with the library's ___location in memory.

The executable then uses this information to call functions and access data stored in the library.

This type of dynamic linking is called ''loadtime linking'' and is used by most operating systems including [[Microsoft Windows|Windows]] and [[Linux]].

Loadtime linking is one of the most complex routines the loader performs while loading an application.

Inspired by von Neumann, [[Maurice Wilkes|Wilkes]] and his team constructed [[EDSAC]]. A [[filing cabinet]] of [[punched tape]] held the subroutine library for this computer.<ref>{{Cite conference|last=Wilkes|first=M. V.| title=1951 International Workshop on Managing Requirements Knowledge |date=1951|chapter=The EDSAC Computer| page=79 |chapter-url=http://dx.doi.org/10.1109/afips.1951.13|conference=1951 International Workshop on Managing Requirements Knowledge|publisher=IEEE|doi=10.1109/afips.1951.13}}</ref> Programs for EDSAC consisted of a main program and a sequence of subroutines copied from the subroutine library.<ref>{{cite journal |last1=Campbell-Kelly |first1=Martin |date=September 2011 |title=In Praise of 'Wilkes, Wheeler, and Gill' |url=https://cacm.acm.org/magazines/2011/9/122802-in-praise-of-wilkes-wheeler-and-gill/fulltext |journal=Communications of the ACM |volume=54 |issue=9 |pages=25–27 |doi=10.1145/1995376.1995386|s2cid=20261972 |url-access=subscription }}</ref> In 1951 the team published the first textbook on programming, ''[[The Preparation of Programs for an Electronic Digital Computer]]'', which detailed the creation and the purpose of the library.<ref>{{cite book |last1=Wilkes |first1=Maurice |last2=Wheeler |first2=David |last3=Gill |first3=Stanley |author-link1=Maurice Wilkes |author-link2=David Wheeler (computer scientist) |author-link3=Stanley Gill |date=1951 |title=The Preparation of Programs for an Electronic Digital Computer |oclc=641145988 |url=https://archive.org/details/programsforelect00wilk/page/80/mode/2up?q=library |___location= |publisher=Addison-Wesley |pages=45, 80–91, 100 |isbn=}}</ref>

Other operating systems resolve dependencies at runtime. For these systems, the executable calls an operating system API, passing it the name of a library file, a function number within the library and the function's parameters. The operating system resolves the import immediately and calls the appropriate function on behalf of the application. This type of dynamic linking is called ''runtime linking''. Because of the overhead added to each call, runtime linking is incredibly slow and negatively affects an executable's performance. As a result, runtime linking is rarely used by modern operating systems.

[[COBOL]] included "primitive capabilities for a library system" in 1959,<ref name="Wexelblat_1981_247">{{Cite book |last=Wexelblat |first=Richard |title=History of Programming Languages |publisher=Academic Press (A subsidiary of [[Harcourt Brace]]) |year=1981 |series=ACM Monograph Series |publication-place=New York, NY |isbn=0-12-745040-8 |page=[https://archive.org/details/historyofprogram0000hist/page/274 274] |url=https://archive.org/details/historyofprogram0000hist/page/274 }}</ref> but [[Jean E. Sammet|Jean Sammet]] described them as "inadequate library facilities" in retrospect.<ref name="Wexelblat_1981_258">Wexelblat, ''op. cit.'', p. 258</ref>

In dynamic linking the library, commonly referred to as a ''dynamic link library'' (DLL) or ''shared library'', is a pre-compiled and linked executable file which is stored separately on the computer's [[hard disk]]. It is loaded only when needed by an application. In most cases, multiple applications can use the same copy of the library at the same time and there is no need for the operating system to load multiple ''instances'' of the library into memory concurrently. In these cases, the libraries are stateless.

That is, any data which must be stored by the library is stored by the application(s) it is serving. For this reason, these dynamic libraries are considered ''in-process''.

[[JOVIAL]] has a Communication Pool (COMPOOL), roughly a library of header files.

One of the largest disadvantages of dynamic linking is that the executables depend on the separately stored libraries in order to function properly.

If the library is deleted, moved, renamed or replaced with an incompatible version, the executable could malfunction.

On Windows this is commonly known as [[DLL-hell]].

Another major contributor to the modern library concept came in the form of the [[subprogram]] innovation of [[FORTRAN]]. FORTRAN subprograms can be compiled independently of each other, but the compiler lacked a [[Linker (computing)|linker]]. So prior to the introduction of modules in Fortran-90, [[type checking]] between FORTRAN<ref group=NB>It was possible earlier between, e.g., Ada subprograms.</ref> subprograms was impossible.<ref name="Wilson_Clark_1988_126">{{Cite book |last1=Wilson |first1=Leslie B. |last2=Clark |first2=Robert G.|title=Comparative Programming Languages|publisher=Addison-Wesley |year=1988 |publication-place=Wokingham, England |isbn=0-201-18483-4 |page=126 }}</ref>

Dynamic linking libraries date back to at least MTS (the Michigan Terminal System), built in the late 60s. ("A History of MTS", ''Information Technology Digest'', Vol. 5, No. 5)

By the mid 1960s, copy and macro libraries for assemblers were common. Starting with the popularity of the [[IBM System/360]], libraries containing other types of text elements, e.g., system parameters, also became common.

===Naming===

*[[GNU]]/[[Linux]], [[Solaris Operating Environment|Solaris]] and [[BSD]] variants: <code>libfoo.so</code> files in folders like <code>/lib</code>, <code>/usr/lib</code> or <code>/usr/local/lib</code> are dynamically linked libraries. The filenames always start with <code>lib</code>, and end with <code>.so</code> (shared object), with an optional interface number, for example <code>libfoo.so.2</code> is the second interface revision of the library <code>libfoo</code>.

*[[MacOS X]] and upwards: libraries are named <code>libfoo.dylib</code>, with an optional interface number, such as <code>libfoo.2.dylib</code>.

*[[Microsoft Windows]]: <code>*.DLL</code> files are dynamically linked libraries. The interface revisions are encoded in the files, or abstracted away using [[component object model|COM-object]] interfaces.

In [[OS/360 and successors|IBM's OS/360 and its successors]] this is called a [[Data set (IBM mainframe)#Partitioned datasets|partitioned data set]].

== Shared library ==

Libraries can be linked dynamically. In [[Microsoft Windows]], those are called '''dynamic linked libraries''', or '''DLLs'''. Conventional libraries are often called static library to distinguish from shared libraries.

The first [[object-oriented programming]] language, [[Simula]], developed in 1965, supported adding [[Class (computer science)|classes]] to libraries via its compiler.<ref name="Wilson_Clark_1988_52">Wilson and Clark, ''op. cit.'', p. 52</ref><ref name="Wexelblat_1981_716">Wexelblat, ''op. cit.'', p. 716</ref>

The shared library term is slightly ambiguous, because it covers at least two different concepts. First, it is the sharing of code located on disk by unrelated programs. The second concept is the sharing of code in memory, when programs execute the same physical page of RAM, mapped into different address spaces. RAM sharing can be accomplished by using [[position independent code]] as in [[Unix]], which leads to a complex but flexible architecture, or by using normal, ie. not position independent code like in [[Microsoft Windows]] and [[OS/2]], but making sure, by various tricks like pre-mapping the address space and reserving slots for each DLL, that code has a great probability of being shared. Windows DLLs are not shared libraries in the Unix sense. The rest of this article concentrates on aspects common to both variants.

==Linking==

A DLL is a software library (often stored in a [[computer file|file]]) consisting of a collection of resources or routines that are available to other programs. A program that wants to use these routines is linked (see [[linker]]) with the DLL at the time it is actually started or later. Oppose this with a [[static library]], the contents of which are copied into the program when the program is compiled and linked.

The ''linking'' (or ''binding'') process resolves references known as ''symbols'' (or ''links'') by searching for them in various locations including configured libraries. If a [[linker (computing)|linker]] (or binder) does not find a symbol, then it fails, but multiple matches may or may not cause failure.

''Static linking'' is linking at [[link time|build time]], such that the library executable code is included in the program. ''Dynamic linking'' is linking at [[Runtime (program lifecycle phase)|run time]]; it involves building the program with information that supports run-time linking to a dynamic link library (DLL). For dynamic linking, a compatible DLL file must be available to the program at run time, but for static linking, the program is standalone.

A program performing the former task is called a [[Loader (computing)|loader]], while the latter task is accomplished by a [[linker]]. However, to link a program against a DLL, thus making the program request that a particular DLL be loaded when it is started, the linker also needs to look into the DLL to verify that all symbols (routines and variables) used by the program are actually provided by the DLL, thus leaving the impression that ''dynamic'' linking is performed at ''compile time'', while it actually happens at ''run time'' (in most cases, at ''program start time'').

{{anchor|Smart linking}}''Smart linking'' is performed by a build tool that excludes unused code in the linking process. For example, a program that only uses integers for arithmetic, or does no arithmetic operations at all, can exclude floating-point library routines. This can lead to smaller program file size and reduced memory usage.

The process of making resources available to other programs is called ''exporting''. Most common forms of exports include ''[[procedure]]s'' ([[function (programming)|functions]], routines, subroutines), ''[[variable]]s'', and some sorts of static data, e.g. icons. Exported procedures are also called ''entry points'', because invoking them is akin to "entering" the library. In order to allow access to them, the resources receive names, which are written down inside a table, also containing their offsets inside the file. These names (and sometimes, by analogy, the resources they represent) are called ''symbols''. Similarly, the table is called a ''[[symbol table]]''.

==Relocation==

In most modern [[operating system]]s, shared libraries can be of the same format as the "regular" executables. This allows two main advantages: first, it requires making only one loader for them, rather than two. Secondly, it allows the executables also to be used as DLLs, if they have a symbol table (see below). Typical executable/DLL formats are [[Executable and Linkable Format|ELF]] ([[UNIX]]) and [[Portable Executable|PE]] ([[Microsoft Windows]]). In Windows, the concept was taken one step further, with even system resources such as fonts being bundled in the DLL file format.

Some references in a program or library module are stored in a relative or symbolic form which cannot be resolved until all code and libraries are assigned final static addresses. [[Relocation (computer science)|Relocation]] is the process of adjusting these references, and is done either by the linker or the [[loader (computing)|loader]]. In general, relocation cannot be done to individual libraries themselves because the addresses in memory may vary depending on the program using them and other libraries they are combined with. [[Position-independent code]] avoids references to absolute addresses and therefore does not require relocation.

== Categories ==

Executables are less likely to have a symbol table (they are not mandatory and are usually stripped down to save space), as opposed to DLLs which need one to serve their purpose. Aside from that, from most other aspects, the difference between DLLs and executables in modern operating systems is mostly conventional, as the other [[data structures]] are shared between the two types of files. Both have a record pointing at a main entry point. While an executable's main entry point is used by the operating system to launch it, the operating system uses a DLL's main entry point only when it is loaded by some application, to initialize that DLL. In other words, the user of the operating system cannot directly cause the invokation of the main (or indeed any other) entry point of a DLL.

=== Executable ===

The term DLL is mostly used on Windows and [[OS/2]] products. On the UNIX platform, the term ''shared library'' is more commonly used. This is technically justified in view of the different semantics. More explanations are available in the [[position independent code]] article.

An executable library consists of code that has been converted from source code into [[machine code]] or an intermediate form such as [[bytecode]]. A linker allows for using library objects by associating each reference with an address at which the object is located. For example, in [[C (programming language)|C]], a library function is invoked via C's normal function call [[Syntax (programming languages)|syntax]] and [[Semantics (computer science)|semantics]].<ref>{{Cite thesis|title=Metamorphic Detection Using Function Call Graph Analysis|publisher=San Jose State University Library|first=Prasad|last=Deshpande| year=2013 |doi=10.31979/etd.t9xm-ahsc|doi-access=free}}</ref>

In some cases, an operating system can become overloaded with different versions of DLLs, which impedes its performance and stability. Such a scenario is known as [[DLL-hell]].

A variant is a library containing compiled code (object code in IBM's nomenclature) in a form that cannot be loaded by the OS but that can be read by the linker.

== See also ==

* GNU [[Libtool]]

* [[Software engineering]]

* [[List of software engineering topics]]

=== External linkStatic ===

A [[static library]] is an executable library that is linked into a program at build-time by a linker (or whatever the build tool is called that does linking).<ref name="Static Libraries">{{cite web|title=Static Libraries|url=http://tldp.org/HOWTO/Program-Library-HOWTO/static-libraries.html|publisher=TLDP|access-date=3 October 2013|url-status=live|archive-url=https://web.archive.org/web/20130703011904/http://tldp.org/HOWTO/Program-Library-HOWTO/static-libraries.html|archive-date=3 July 2013}}</ref><ref>{{cite book|last=Kaminsky|first=Dan|chapter=Chapter 3 - Portable Executable and Executable and Linking Formats|date=2008|chapter-url=http://dx.doi.org/10.1016/b978-1-59749-237-9.00003-x|title=Reverse Engineering Code with IDA Pro|pages=37–66|publisher=Elsevier|doi=10.1016/b978-1-59749-237-9.00003-x|isbn=978-1-59749-237-9|access-date=2021-05-27}}</ref> This process, and the resulting stand-alone file, is known as a [[static build]] of the program. A static build may not need any further [[relocation (computer science)|relocation]] if [[virtual memory]] is used and no [[address space layout randomization]] is desired.<ref>{{cite conference|url=http://usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html|title=SLINKY: Static Linking Reloaded|conference=USENIX '05|first1=Christian |last1=Collberg |first2=John H. |last2=Hartman |first3=Sridivya |last3=Babu |first4=Sharath K. |last4=Udupa|publisher=Department of Computer Science, [[University of Arizona]]|access-date=2016-03-17|year=2003|url-status=live|archive-url=https://web.archive.org/web/20160323214637/https://www.usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html|archive-date=23 March 2016}}</ref>

* [http://www.dwheeler.com/program-library/ Program Library HOWTO] for [[GNU/Linux]]

A static library is sometimes called an ''archive'' on Unix-like systems.

[[de:Bibliothek (Programmierung)]]

[[et:Teek]]

=== Dynamic ===

[[es:Biblioteca (programa)]]

[[fr:Bibliothèque (logicielle)]]

A [[dynamic library]] is linked when the program is run {{endash}} either at [[load-time]] or [[Runtime (program lifecycle phase)|runtime]]. The dynamic library was intended after the static library to support additional [[software deployment]] flexibility.

[[hu:Dinamikus csatolású könyvtár]]

[[nl:Library]]

=== Sources ===

[[ru:&#1041;&#1080;&#1073;&#1083;&#1080;&#1086;&#1090;&#1077;&#1082;&#1072; (&#1087;&#1088;&#1086;&#1075;&#1088;&#1072;&#1084;&#1084;&#1080;&#1088;&#1086;&#1074;&#1072;&#1085;&#1080;&#1077;)]]

A source library consists of source code; not compiled code.

[[ja:&#12521;&#12452;&#12502;&#12521;&#12522;]]

[[zh-cn:&#24211;]]

=== Shared ===

[[Category:Computer terminology]]

A [[shared library]] is a library that contains [[executable code]] designed to be used by multiple [[computer program]]s or other libraries at [[Runtime (program lifecycle phase)|runtime]], with only one copy of that code in memory, shared by all programs using the code.<ref>{{cite book |title=Linkers and Loaders |last=Levine |first=John R. |chapter=9. Shared Libraries |isbn=1-55860-496-0 |date=2000}}</ref><ref>{{cite book |title=UNIX System V/386 Release 3.2 Programmers Guide, Vol. 1 |url=http://www.bitsavers.org/pdf/att/unix/System_V_386_Release_3.2/UNIX_System_V_386_Release_3.2_Programmers_Guide_Vol1_1989.pdf |page=8{{hyp}}2 |isbn=0-13-944877-2 |date=1989|publisher=Prentice Hall }}</ref><ref>{{cite web |url=https://www.cs.cornell.edu/courses/cs414/2001FA/sharedlib.pdf |title=Shared Libraries in SunOS |pages=1, 3}}</ref>

=== Object ===

Although generally an obsolete technology today, an object library exposes resources for [[object-oriented programming]] (OOP) and a distributed object is a remote object library. Examples include: [[Component Object Model|COM]]/DCOM, [[System Object Model|SOM]]/DSOM, [[Distributed Objects Everywhere|DOE]], [[Portable Distributed Objects|PDO]] and various [[CORBA]]-based systems.

The object library technology was developed since as OOP became popular, it became apparent that OOP runtime binding required information than contemporary libraries did not provide. In addition to the names and entry points of the code located within, due to inheritance, OOP binding also requires a list of dependencies {{endash}} since the full definition of a method may be in different places. Further, this requires more than listing that one library requires the services of another. In OOP, the libraries themselves may not be known at [[compile time]], and vary from system to system.

The remote object technology was developed in parallel to support multi-tier programs with a [[user interface]] application running on a [[personal computer]] (PC) using services of a [[Mainframe computer|mainframe]] or [[minicomputer]] such as data storage and processing. For instance, a program on a PC would send messages to a minicomputer via [[remote procedure call]] (RPC) to retrieve relatively small samples from a relatively large dataset. In response, distributed object technology was developed.

=== Class ===

A class library contains [[Class (computer science)|classes]] that can be used to create [[object (computer science)|objects]]. In [[Java (programming language)|Java]], for example, classes are contained in [[jar (file format)|JAR files]] and objects are created at runtime from the classes. However, in [[Smalltalk]], a class library is the starting point for a [[system image]] that includes the entire state of the environment, classes and all instantiated objects. Most class libraries are stored in a [[package repository]] (such as Maven Central for Java). Client code explicitly specifies dependencies to external libraries in build configuration files (such as a Maven Pom in Java).

=== Remote ===

A remote library runs on another computer and its assets are accessed via [[remote procedure call]] (RPC) over a network. This [[Distributed computing|distributed architecture]] allows for minimizing installation of the library and support for it on each consuming system and ensuring consistent versioning. A significant downside is that each library call entails significantly more overhead than for a local library.

=== Runtime ===

A [[runtime library]] provides access to the [[runtime environment]] that is available to a program {{endash}} tailored to the host [[computer platform|platform]].

=== Language standard ===

Many modern [[programming languages]] specify a [[standard library]] that provides a base level of functionality for the language environment.

=== Code generation ===

A code generation library has a high-level [[Application Programming Interface|API]] generating or transforming [[byte code]] for [[Java (programming language)|Java]]. They are used by [[aspect-oriented programming]], some data access frameworks, and for testing to generate dynamic proxy objects. They also are used to intercept field access.<ref>{{cite web

|access-date = 2010-03-03

|publisher = [[Source Forge]]

|title = Code Generation Library

|url = https://sourceforge.net/projects/cglib/

|quote = Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.

|url-status = live

|archive-url = https://web.archive.org/web/20100112154306/http://sourceforge.net/projects/cglib/

|archive-date = 12 January 2010

}}</ref>

==File naming==

===Unix-like===

On most modern [[Unix-like]] systems, library files are stored in directories such as <code>/lib</code>, <code>/usr/lib</code> and <code>/usr/local/lib</code>. A filename typically starts with <code>lib</code>, and ends with <code>.a</code> for a static library ([[Ar (file format)|archive]]) or <code>.so</code> for a shared object (dynamically linked library). For example, <code>libfoo.a</code> and <code>libfoo.so</code>.

Often, [[symbolic link]] files are used to manage versioning of a library by providing a link file named without a version that links to a file named with a version. For example, <code>libfoo.so.2</code> might be version 2 of library ''foo'' and a link file named <code>libfoo.so</code> provides a version independent name to that file that programs link to. The link file could be changed to a refer to a version 3 (<code>libfoo.so.3</code>) such that consuming programs will then use version 3 without having to change the program.

Files with extension <code>.la</code> are [[libtool]] archives; not usable by the system.

===macOS===

{{see also|Dynamic linker#macOS and iOS}}

The [[macOS]] system inherits static library conventions from [[BSD]], with the library stored in a <code>.a</code> file. It uses either <code>.so</code> or <code>.dylib</code> for dynamic libraries. Most libraries in macOS, however, consist of "frameworks", placed inside special directories called "[[Bundle (macOS)|bundles]]" which wrap the library's required files and metadata. For example, a framework called <code>Abc</code> would be implemented in a bundle called <code>Abc.framework</code>, with <code>Abc.framework/Abc</code> being either the dynamically linked library file or a symlink to the dynamically linked library file in <code>Abc.framework/Versions/Current/Abc</code>.

===Windows===

Often, a [[Microsoft Windows|Windows]] [[dynamic-link library]] (DLL) has the file extension <code>.dll</code>,<ref>

{{cite book

|last1 = Bresnahan

|first1 = Christine

|last2 = Blum

|first2 = Richard

|title = LPIC-1 Linux Professional Institute Certification Study Guide: Exam 101-400 and Exam 102-400

|url = https://books.google.com/books?id=jf3zBgAAQBAJ

|publisher = John Wiley & Sons

|publication-date = 2015

|page = 82

|isbn = 9781119021186

|access-date = 2015-09-03

|quote = Linux shared libraries are similar to the dynamic link libraries (DLLs) of Windows. Windows DLLs are usually identified by <code>.dll</code> filename extensions.

|date = 2015-04-27

|url-status = live

|archive-url = https://web.archive.org/web/20150924234210/https://books.google.com/books?id=jf3zBgAAQBAJ

|archive-date = 24 September 2015

}}

</ref> although sometimes different extensions are used to indicate general content, e.g. <code>.ocx</code> for a [[Object Linking and Embedding|OLE]] library.

A <code>.lib</code> file can be either a static library or contain the information needed to build an application that consumes the associated DLL. In the latter case, the associated DLL file must be present at runtime.

==See also==

* {{annotated link|Code reuse}}

* {{annotated link|Object file}}

* {{annotated link|Plug-in (computing)|Plug-in}}

* {{annotated link|Prelink|aka=prebinding}}

* {{annotated link|Runtime library}}

* {{annotated link|Visual Component Library}} (VCL)

* {{annotated link|Component Library for Cross Platform}} (CLX)

* {{annotated link|C standard library}}

* {{annotated link|Java Class Library}}

* {{annotated link|Framework Class Library}}

* {{annotated link|Generic programming}} (used by the [[C++ Standard Library]])

* {{annotated link|soname}}

* {{annotated link|Method stub}}

* [[List of open source code libraries]]

==Notes==

{{reflist|group=NB}}

==References==

{{reflist}}

==Further reading==

* {{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |___location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |chapter=Chapter 9: Shared Libraries & Chapter 10: Dynamic Linking and Loading |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/]{{dead link|date=May 2025|bot=medic}}{{cbignore|bot=medic}} Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]

* Article ''[http://www.lurklurk.org/linkers/linkers.html Beginner's Guide to Linkers]'' by David Drysdale

* Article ''[https://objprelink.sourceforge.net/objprelink.html Faster C++ program startups by improving runtime linking efficiency]'' by Léon Bottou and John Ryland

* {{usurped|1=[https://web.archive.org/web/20060628062553/http://www.enderunix.org/simsek/articles/libraries.pdf How to Create Program Libraries]}} by Baris Simsek

* [https://sourceware.org/binutils/docs-2.30/bfd/index.html BFD] - the Binary File Descriptor Library

* [http://lcsd05.cs.tamu.edu 1st Library-Centric Software Design Workshop LCSD'05] {{Webarchive|url=https://web.archive.org/web/20190828045251/http://lcsd05.cs.tamu.edu/ |date=2019-08-28 }} at OOPSLA'05

* [https://web.archive.org/web/20060618065018/http://lcsd.cs.tamu.edu/2006/ 2nd Library-Centric Software Design Workshop LCSD'06] at OOPSLA'06

* [http://people.redhat.com/drepper/dsohowto.pdf How to create shared library] by Ulrich Drepper (with much background info)

* [http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/ Anatomy of Linux dynamic libraries] at IBM.com

{{Computer science}}

{{Application binary interface}}

{{Executables}}

{{Authority control}}

{{DEFAULTSORT:Library (Computing)}}

[[Category:Computer libraries| ]]

[[Category:Operating system technology]]