Content deleted Content added
Stevebroshar (talk | contribs) →Categories: Add dynamic and clarify shared |
Peter Flass (talk | contribs) introduce API |
||
| (37 intermediate revisions by 20 users not shown) | |||
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]]
In [[
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, its [[application programming interface]] (API) {{endash}} not its
== 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."<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.]]
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
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>
[[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>
Line 26 ⟶ 25:
[[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 (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>
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.
Line 34 ⟶ 31:
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]].
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>
==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 (computing)|linker]] (or binder) does not find a symbol, then it fails, but multiple matches may or may not cause failure.
''Static linking''
{{anchor|Smart linking}}''Smart linking''
==Relocation==
Line 50 ⟶ 45:
== Categories ==
===
Generally, modern [[programming languages]] specify a [[standard library]] that provides the system services required for application development.▼
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>
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 libraries===▼
A [[static library]] is an executable library that is linked into a program at build-time by a [[linker (computing)|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
A static library is sometimes called an ''archive'' on Unix-like systems.
=== Dynamic
A [[dynamic library]] is linked when the program is run {{endash}} either at [[load-time]] or [[Runtime (program lifecycle phase)|runtime]].
=== Sources ===
▲A [[dynamic library]] is linked when the program is run {{endash}} either at [[load-time]] or [[Runtime (program lifecycle phase)|runtime]]. Originally, only static libraries existed. Dynamic linking was invented later.
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 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.
At the same time many developers worked on the idea of multi-tier programs, in which a "display" running on a desktop computer would use the services of a [[Mainframe computer|mainframe]] or [[minicomputer]] for data storage or processing. For instance, a program on a GUI-based computer would send messages to a minicomputer to return small samples of a huge dataset for display. [[Remote procedure call]]s (RPC) already handled these tasks, but there was no standard RPC 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.
▲
=== Class
=== 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 [[runtime library]] provides access to the [[runtime environment]] that is available to a program {{endash}} tailored to the host [[computer platform|platform]].
=== Language standard ===
▲
=== Code generation
|access-date = 2010-03-03
|publisher = [[Source Forge]]
Line 111 ⟶ 108:
===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>.
Line 133 ⟶ 131:
|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.
Line 140 ⟶ 138:
* {{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)
Line 156 ⟶ 150:
* {{annotated link|soname}}
* {{annotated link|Method stub}}
* [[List of open source code libraries]]
==Notes==
Line 164 ⟶ 159:
==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 ''[
* {{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
| |||