Library (computing): Difference between revisions

Revision as of 10:08, 1 February 2025

Latest revision as of 01:09, 10 August 2025

(46 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 [[computer sciencecomputing]], a '''library''' is a collection of [[System resource|resources]] that iscan be leveragedused 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]].

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

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

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

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>

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

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

=={{anchor|Smart linking}}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.

{{main|Link time|Linker (computing)}}

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

Libraries are important in the program ''linking'' or ''binding'' process, which resolves references known as ''links'' or ''symbols'' to library modules. The linking process is usually automatically done by a ''[[linker (computing)|linker]]'' or ''binder'' program that searches a set of libraries and other modules in a given order. Usually it is not considered an error if a link target can be found multiple times in a given set of libraries. Linking may be done when an executable file is created (static linking), or whenever the program is used at [[Runtime (program lifecycle phase)|runtime]] (dynamic linking).

Some programming languages use a feature called{{anchor|Smart linking}}''smartSmart linking'' whereby the linker is awareperformed ofby ora integratedbuild with the compiler, suchtool that the linker knows how external references are used,excludes andunused code in a library that is never actually ''used'', even though internally referenced, can be discarded from the compiledlinking applicationprocess. For example, a program that only uses integers for arithmetic, or does no arithmetic operations at all, can exclude floating-point library routines. This smart-linking feature can lead to smaller applicationprogram file sizessize and reduced memory usage.

The references being resolved may be addresses for jumps and other routine calls. They may be in the main program, or in one module depending upon another. They are resolved into fixed or relocatable addresses (from a common base) by allocating runtime memory for the [[memory segment]]s of each module referenced.

Some programming languages use a feature called ''smart linking'' whereby the linker is aware of or integrated with the compiler, such that the linker knows how external references are used, and code in a library that is never actually ''used'', even though internally referenced, can be discarded from the compiled application. For example, a program that only uses integers for arithmetic, or does no arithmetic operations at all, can exclude floating-point library routines. This smart-linking feature can lead to smaller application file sizes 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'' (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.

{{Main|Relocation (computer science)}}

== Categories ==

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

=== Executable libraries ===

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 capability.[[Syntax The(programming linkerlanguages)|syntax]] generatesand code[[Semantics to call(computer a function via the library mechanism if the function is available from a library instead of from the program itselfscience)|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 library of executable code has a well-defined [[interface (computing)|interface]] by which the functionality is invoked.

For example, in [[C (programming language)|C]], a library function is invoked via C's normal function call capability. The linker generates code to call a function via the library mechanism if the function is available from a library instead of from the program itself.<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.

The functions of a library can be connected to the invoking program at different [[program lifecycle phase]]s. If the code of the library is accessed during the build of the invoking program, then the library is called a [[static library]].<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> An alternative is to build the program executable to be separate from the library file. The library functions are connected after the executable is started, either at [[load-time]] or [[Runtime (program lifecycle phase)|runtime]]. In this case, the library is called a [[dynamic library]].

=== Static libraries===

Most [[compiled language]]s have a [[standard library]], although programmers can also create their own custom libraries. Most modern software systems provide libraries that implement the majority of the system services. Such libraries have organized the services which a modern application requires. As such, most code used by modern applications is provided in these system libraries.

AllA of[[static thelibrary]] modulesis requiredan byexecutable library that is linked into a program areat sometimesbuild-time staticallyby linkeda andlinker copied(or intowhatever the executablebuild filetool 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.

==Static libraries==

{{Main|Static library}}

=== Dynamic ===

When linking is performed during the creation of an executable or another object file, it is known as ''static linking'' or ''early binding''. In this case, the linking is usually done by a [[linker (computing)|linker]], but may also be done by the [[compiler]].<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> A ''static library'', also known as an ''archive'', is one intended to be statically linked. Originally, only static libraries existed. Static linking must be performed when any modules are recompiled.

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.

All of the modules required by a program are sometimes statically linked and copied into the executable file. 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>

==Shared= librariesSources ===

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

{{Main|Shared library}}

=== Shared ===

A '''shared library''' or '''shared object''' is a file that is intended to be shared by [[executable files]] and further shared [[object file]]s. Modules used by a program are loaded from individual shared objects into memory at [[load time]] or [[Runtime (program lifecycle phase)|runtime]], rather than being copied by a linker when it creates a single monolithic executable file for the program.

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

Shared libraries can be statically linked during compile-time, meaning that references to the library modules are resolved and the modules are allocated memory when the executable file is created.{{citation needed|date=June 2023}} But often linking of shared libraries is postponed until they are loaded.{{Dubious|date=May 2014}}

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.

==Object libraries==

Although originally pioneered in the 1960s, dynamic linking did not reach the most commonly-used [[operating system]]s until the late 1980s. It was generally available in some form in most operating systems by the early 1990s. During this same period, [[object-oriented programming]] (OOP) was becoming a significant part of the programming landscape. OOP with runtime binding requires additional information that traditional libraries do not supply. In addition to the names and entry points of the code located within, they also require a list of the objects they depend on. This is a side-effect of one of OOP's core concepts, inheritance, which means that parts of the complete definition of any method may be in different places. This is more than simply listing that one library requires the services of another: in a true OOP system, 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.

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.

AtThe theremote sameobject timetechnology manywas developersdeveloped workedin onparallel theto idea ofsupport multi-tier programs, in whichwith a "display"[[user interface]] application running on a desktop[[personal computer]] would use(PC) theusing services of a [[Mainframe computer|mainframe]] or [[minicomputer]] forsuch as data storage orand processing. For instance, a program on a GUI-based computerPC would send messages to a minicomputer to return small samples of a huge dataset for display.via [[Remoteremote procedure call]]s (RPC) alreadyto handledretrieve theserelatively tasks,small butsamples therefrom wasa norelatively standardlarge RPCdataset. In response, distributed object technology was systemdeveloped.

Soon the majority of the minicomputer and mainframe vendors instigated projects to combine the two, producing an OOP library format that could be used anywhere. Such systems were known as '''object libraries''', or '''distributed objects''', if they supported remote access (not all did). Microsoft's COM is an example of such a system for local use. DCOM, a modified version of COM, supports remote access.

=== Class libraries===

For some time object libraries held the status of the "next big thing" in the programming world. There were a number of efforts to create systems that would run across platforms, and companies competed to try to get developers locked into their own system. Examples include [[IBM]]'s [[System Object Model]] (SOM/DSOM), [[Sun Microsystems]]' [[Distributed Objects Everywhere]] (DOE), [[NeXT]]'s [[Portable Distributed Objects]] (PDO), [[Digital Equipment Corporation|Digital]]'s [[ObjectBroker]], Microsoft's [[Component Object Model]] (COM/DCOM), and any number of [[CORBA]]-based systems.

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

==Class libraries==

=== Remote libraries===

'''Class libraries''' are the rough OOP equivalent of older types of code libraries. They contain [[Class (computer science)|classes]], which describe characteristics and define actions ([[Method (computer science)|methods]]) that involve objects. Class libraries are used to create [[Instance (computer science)|instances]], or objects with their characteristics set to specific values. In some OOP languages, like [[Java (programming language)|Java]], the distinction is clear, with the classes often contained in library files (like Java's [[jar (file format)|JAR file format]]) and the instantiated objects residing only in memory (although potentially able to be made [[Persistence (computer science)|persistent]] in separate files). In others, like [[Smalltalk]], the class libraries are merely the starting point for a [[system image]] that includes the entire state of the environment, classes and all instantiated objects.

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

Today most class libraries are stored in a [[package repository]] (such as Maven Central for Java). Client code explicitly declare the dependencies to external libraries in [[Software build|build]] configuration files (such as a Maven Pom in Java).

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

==Remote libraries==

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

Another library technique uses completely separate executables (often in some lightweight form) and calls them using a [[remote procedure call]] (RPC) over a network to another computer. This maximizes operating system re-use: the code needed to support the library is the same code being used to provide application support and security for every other program. Additionally, such systems do not require the library to exist on the same machine, but can forward the requests over the network.

=== Code generation libraries===

However, such an approach means that every library call requires a considerable amount of overhead. RPC calls are much more expensive than calling a shared library that has already been loaded on the same machine. This approach is commonly used in a [[Distributed computing|distributed architecture]] that makes heavy use of such remote calls, notably client-server systems and [[application server]]s such as [[Enterprise JavaBean]]s.

CodeA code generation librarieslibrary arehas a high-level [[Application Programming Interface|API]]s that can generategenerating or transformtransforming [[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

==Code generation libraries==

Code generation libraries are high-level [[Application Programming Interface|API]]s that can generate or transform [[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]]

Line 108 ⟶ 100:

==File naming==

===Most modern Unix-like systems===

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

{{See also|Unix-like}}

The system stores <code>libfoo.a</code> and <code>libfoo.so</code> files in directories such as <code>/lib</code>, <code>/usr/lib</code> or <code>/usr/local/lib</code>. The filenames always start with <code>lib</code>, and end with a suffix of <code>.a</code> ([[Ar (file format)|archive]], static library) or of <code>.so</code> (shared object, dynamically linked library). Some systems might have multiple names for a dynamically linked library. These names typically share the same prefix and have different suffixes indicating the version number. Most of the names are names for [[symbolic links]] to the latest version. For example, on some systems <code>libfoo.so.2</code> would be the filename for the second major interface revision of the dynamically linked library <code>libfoo</code>. The <code>.la</code> files sometimes found in the library directories are [[libtool]] archives, not usable by the system as such.

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

{{Seesee 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,. andIt canuses useeither <code>.so</code>-style dynamically linked libraries (with theor <code>.dylib</code> suffixfor instead)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>MyFrameworkAbc</code> would be implemented in a bundle called <code>MyFrameworkAbc.framework</code>, with <code>MyFrameworkAbc.framework/MyFrameworkAbc</code> being either the dynamically linked library file or being a symlink to the dynamically linked library file in <code>MyFrameworkAbc.framework/Versions/Current/MyFrameworkAbc</code>.

===Microsoft Windows===

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

{{See also|Microsoft Windows}}

[[Dynamic-link library|Dynamic-link libraries]] usually have the suffix <code>*.DLL</code>,<ref>

{{cite book

|last1 = Bresnahan

Line 137 ⟶ 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.

</ref> although other file name extensions may identify specific-purpose dynamically linked libraries, e.g. <code>*.OCX</code> for [[Object Linking and Embedding|OLE]] libraries. The interface revisions are either encoded in the file names, or abstracted away using [[component object model|COM-object]] interfaces. Depending on how they are compiled, <code>*.LIB</code> files can be either static libraries or representations of dynamically linkable libraries needed only during compilation, known as "[[Dynamic-link library#Import libraries|import libraries]]". Unlike in the [[UNIX]] world, which uses different file extensions, when linking against <code>.LIB</code> file in [[Microsoft Windows|Windows]] one must first know if it is a regular static library or an import library. In the latter case, a <code>.DLL</code> file must be present at runtime.

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|Linker (computing)}}

* {{annotated link|Loader (computing)}}

* {{annotated link|Dynamic-link library}}

* {{annotated link|Object file}}

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

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

* {{annotated link|Static library}}

* {{annotated link|Runtime library}}

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

Line 158 ⟶ 150:

* {{annotated link|soname}}

* {{annotated link|Method stub}}

* [[List of open source code libraries]]

==Notes==

Line 166 ⟶ 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 ''[httphttps://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