Library (computing): Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
imported>BunnysBot
Fix CW Errors with GenFixes (T1)
 
imported>Curlyquote
m Punctuation
 
(2 intermediate revisions by 2 users not shown)
Line 5: Line 5:
[[Image:Ogg vorbis libs and application dia.svg|thumb|277px|right|Illustration of an application which uses libvorbisfile to play an [[Ogg Vorbis]] file]]
[[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 leveraged 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]].
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 (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]].


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.
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.


When writing code that uses a library, a [[programmer]] only needs to know how to use it {{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.
When writing code that uses a library, a [[programmer]] only needs to know how to use that library's [[application programming interface]] (API) without understanding its internal mechanics. 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.


== History ==
== History ==
Line 15: Line 15:
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>
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>


[[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.]]
[[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]]


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 |last1=Goldstine |first1=Herman |last2=von Neumann |first2=John |author-link1=Herman Goldstine |author-link2=John von Neumann |date=1947 |title=Planning and coding of problems for an electronic computing instrument |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>
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>


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>
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>
Line 51: Line 51:
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.
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.


===Static===
=== Static ===
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>
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>


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


===Dynamic===
=== Dynamic ===


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.
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.


===Sources===
=== Sources ===
A source library consists of source code; not compiled code.
A source library consists of source code, not compiled code.


===Shared===
=== Shared ===
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>
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===
=== 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.
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.
Line 72: Line 72:
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 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, distrubuted object technology was developed.
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===
=== 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).
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===
=== 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.
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.


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


===Code generation===
=== 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
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
  |access-date  = 2010-03-03
Line 105: Line 105:
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.
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.
Files with the extension <code>.la</code> are [[libtool]] archives; they are not usable by the system.


===macOS===
===macOS===
Line 161: Line 161:
* {{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 -->]
* {{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 ''[http://www.lurklurk.org/linkers/linkers.html Beginner's Guide to Linkers]'' by David Drysdale
* Article ''[http://objprelink.sourceforge.net/objprelink.html Faster C++ program startups by improving runtime linking efficiency]'' by Léon Bottou and John Ryland
* 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
* {{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
* [https://sourceware.org/binutils/docs-2.30/bfd/index.html BFD] - the Binary File Descriptor Library

Latest revision as of 08:46, 15 December 2025

Template:Short description Template:Redirect-distinguish Script error: No such module "about". Template:Use dmy dates

File:Ogg vorbis libs and application dia.svg
Illustration of an application which uses libvorbisfile to play an Ogg Vorbis file

In computing, a library is a collection of resources that can be used during software development to implement a computer program. Commonly, a library consists of executable code such as compiled functions and classes, or a library can be a collection of source code. A resource library may contain data such as images and text.

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 fashion. Libraries can use other libraries resulting in a hierarchy of libraries in a program.

When writing code that uses a library, a programmer only needs to know how to use that library's application programming interface (API) without understanding its internal mechanics. For example, a program could use a library that 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.

History

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."[1]

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

In 1947 Goldstine and von Neumann speculated that it would be useful to create a "library" of subroutines for their work on the IAS machine, an early computer that was not yet operational at that time.[2] They envisioned a physical library of magnetic wire recordings, with each wire storing reusable computer code.[3]

Inspired by von Neumann, Wilkes and his team constructed EDSAC. A filing cabinet of punched tape held the subroutine library for this computer.[4] Programs for EDSAC consisted of a main program and a sequence of subroutines copied from the subroutine library.[5] 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.[6]

COBOL included "primitive capabilities for a library system" in 1959,[7] but Jean Sammet described them as "inadequate library facilities" in retrospect.[8]

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

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. So prior to the introduction of modules in Fortran-90, type checking between FORTRAN[NB 1] subprograms was impossible.[9]

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.

In IBM's OS/360 and its successors this is called a partitioned data set.

The first object-oriented programming language, Simula, developed in 1965, supported adding classes to libraries via its compiler.[10][11]

Linking

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 (or binder) does not find a symbol, then it fails, but multiple matches may or may not cause failure.

Static linking is linking at build time, such that the library executable code is included in the program. Dynamic linking is linking at 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.

Script error: No such module "anchor".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.

Relocation

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 is the process of adjusting these references, and is done either by the linker or the 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

Executable

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, a library function is invoked via C's normal function call syntax and semantics.[12]

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.

Static

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).[13][14] 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 if virtual memory is used and no address space layout randomization is desired.[15]

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

Dynamic

A dynamic library is linked when the program is run

  1. REDIRECT Template:En dash

Template:R protected either at load-time or runtime. The dynamic library was intended after the static library to support additional software deployment flexibility.

Sources

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

Shared

A shared library is a library that contains executable code designed to be used by multiple computer programs or other libraries at runtime, with only one copy of that code in memory, shared by all programs using the code.[16][17][18]

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: COM/DCOM, SOM/DSOM, DOE, 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

  1. REDIRECT Template:En dash

Template:R protected 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 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 classes that can be used to create objects. In Java, for example, classes are contained in 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 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

  1. REDIRECT Template:En dash

Template:R protected tailored to the host 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 API generating or transforming byte code for 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.[19]

File naming

Unix-like

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

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, libfoo.so.2 might be version 2 of library foo and a link file named libfoo.so 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 (libfoo.so.3) such that consuming programs will then use version 3 without having to change the program.

Files with the extension .la are libtool archives; they are not usable by the system.

macOS

Script error: No such module "Labelled list hatnote". The macOS system inherits static library conventions from BSD, with the library stored in a .a file. It uses either .so or .dylib for dynamic libraries. Most libraries in macOS, however, consist of "frameworks", placed inside special directories called "bundles" which wrap the library's required files and metadata. For example, a framework called Abc would be implemented in a bundle called Abc.framework, with Abc.framework/Abc being either the dynamically linked library file or a symlink to the dynamically linked library file in Abc.framework/Versions/Current/Abc.

Windows

Often, a Windows dynamic-link library (DLL) has the file extension .dll,[20] although sometimes different extensions are used to indicate general content, e.g. .ocx for a OLE library.

A .lib 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

Notes

<templatestyles src="Reflist/styles.css" />

  1. It was possible earlier between, e.g., Ada subprograms.

Script error: No such module "Check for unknown parameters".

References

<templatestyles src="Reflist/styles.css" />

  1. Script error: No such module "Citation/CS1".
  2. Script error: No such module "citation/CS1".
  3. Script error: No such module "citation/CS1".
  4. Script error: No such module "citation/CS1".
  5. Script error: No such module "Citation/CS1".
  6. Script error: No such module "citation/CS1".
  7. Script error: No such module "citation/CS1".
  8. Wexelblat, op. cit., p. 258
  9. Script error: No such module "citation/CS1".
  10. Wilson and Clark, op. cit., p. 52
  11. Wexelblat, op. cit., p. 716
  12. Template:Cite thesis
  13. Script error: No such module "citation/CS1".
  14. Script error: No such module "citation/CS1".
  15. Script error: No such module "citation/CS1".
  16. Script error: No such module "citation/CS1".
  17. Script error: No such module "citation/CS1".
  18. Script error: No such module "citation/CS1".
  19. Script error: No such module "citation/CS1".
  20. Script error: No such module "citation/CS1".

Script error: No such module "Check for unknown parameters".

Further reading

Script error: No such module "Navbox". Template:Application binary interface Script error: No such module "Navbox". Template:Authority control