Hubbry Logo
Library (computing)Library (computing)Main
Open search
Library (computing)
Community hub
Library (computing)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Library (computing)
Library (computing)
Library (computing)
View on Wikipedia
from Wikipedia

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 it, its application programming interface (API) – not its internal details. 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

[edit]

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]

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

[edit]

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.

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

[edit]

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

[edit]

Executable

[edit]

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

[edit]

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

[edit]

A dynamic library is linked when the program is run – either at load-time or runtime. The dynamic library was intended after the static library to support additional software deployment flexibility.

Sources

[edit]

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

Shared

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

A runtime library provides access to the runtime environment that is available to a program – tailored to the host platform.

Language standard

[edit]

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

Code generation

[edit]

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

[edit]

Unix-like

[edit]

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 extension .la are libtool archives; not usable by the system.

macOS

[edit]
See also: Dynamic linker § macOS and iOS

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

[edit]

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

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Library (computing)

View on Grokipedia
from Grokipedia
In computing, a software library is a collection of pre-developed software components, such as routines, functions, or classes, that provide specific functionalities to application developers, enabling code reuse, reducing development time, and minimizing redundancy. These libraries are typically organized into binary files for efficient integration into programs and serve as a foundational element in software engineering by encapsulating tested, reusable code for common tasks like mathematical computations or input/output operations. Software libraries originated in the early days of to address the need for modular code in high-performance applications, with notable early examples including the (BLAS) library, developed in the 1970s for optimized numerical computations across architectures, and , an extension from the 1990s focused on linear algebra solvers and eigenvalue problems. They have since evolved into essential tools for boosting programmer productivity and standardizing practices across domains like scientific computing and . There are two primary types of software libraries: static libraries, which are linked into the file at , resulting in a self-contained program with no external dependencies at runtime but potentially larger file sizes; and dynamic libraries (also known as shared libraries), which are loaded at runtime, allowing multiple programs to share the same for and easier updates, though they introduce potential version compatibility issues. Static libraries are preferred for embedded systems or when distribution simplicity is key, while dynamic libraries dominate in modern operating systems like (using .so files) and Windows (using .dll files). The importance of software libraries lies in their role as community-driven knowledge bases that manage complexity, ensure robustness through peer-reviewed implementations, and facilitate interoperability, with prominent examples including the for core language functions and third-party libraries like for numerical computing in Python. By promoting and , libraries have transformed from monolithic coding to collaborative, scalable ecosystems, underpinning advancements in fields from to .

Fundamentals

Definition

In computing, a software library is a collection of pre-compiled routines, functions, classes, or data structures designed to perform common tasks and enable reuse across multiple programs. These components encapsulate tested and optimized code, allowing developers to integrate functionality without rewriting it from scratch. Key characteristics of software libraries include modularity, which organizes code into independent, self-contained units; reusability, permitting the same components to be employed in diverse applications; and abstraction, which hides implementation details from the calling code while exposing only necessary interfaces. This design promotes efficient software development by reducing redundancy and enhancing maintainability. Unlike standalone executables, which are complete programs that can run independently to perform specific operations, libraries serve as modular components that must be linked into applications during compilation or runtime to provide their functionality. For instance, libraries such as the Apache Commons Math provide routines for statistical computations and linear algebra, while (GUI) libraries like those in Java's Swing toolkit offer reusable components for building interactive interfaces.

Purpose and Benefits

Software libraries primarily enable , preventing duplication of effort by allowing developers to incorporate pre-implemented functionalities into new programs rather than writing them from scratch each time. This approach accelerates development by providing access to thoroughly tested components that have already been refined through widespread use, thereby reducing the time required to build and validate software. Furthermore, libraries standardize common operations—such as or handling—across different applications, promoting consistency and easing integration in larger systems. The benefits of libraries extend to enhanced efficiency and quality in . They significantly cut development time and costs by eliminating the need to "reinvent the wheel" for routine tasks, allowing teams to focus on unique aspects of their projects. Reliability improves as libraries often contain mature, debugged code that has undergone extensive testing in diverse environments, lowering the risk of errors in dependent applications. For dynamic libraries, maintenance becomes more straightforward since updates or fixes to the library can propagate to all programs using it without requiring recompilation, avoiding repetitive modifications across multiple codebases and enabling centralized improvements. While libraries offer these advantages, they also involve trade-offs, particularly in dependency management, where handling versions, compatibility issues, and potential conflicts can add complexity to builds and deployments. However, this overhead is frequently offset by the modularity libraries introduce, which supports cleaner separation of concerns and more adaptable software designs. For example, a developer might use Python's Requests library to manage HTTP protocols and handle connections abstractly, avoiding the need to implement low-level socket programming manually for each network-enabled application.

History

Origins

The origins of libraries in computing emerged during the 1940s and 1950s, as programmers developed subroutine libraries in to enable on early electronic computers such as and . On , completed in 1945, the team of programmers, including Betty Snyder Holberton, utilized subroutines to extend the machine's flexibility beyond its initial wiring for specific tasks like ballistic trajectory calculations, allowing repetitive operations to be modularized and invoked as needed. This approach addressed the limitations of ENIAC's plugboard-based programming, where reconfiguration for new problems was labor-intensive. Similarly, on , delivered in 1951, subroutines formed the basis of early software organization, with programmers manually incorporating reusable routines for and arithmetic operations. A key milestone in the 1950s was the development of linking loaders, particularly in systems, which automated the integration of reusable code blocks and reduced manual intervention. Grace Hopper's , implemented in 1952 for the , functioned as an early and linker that automatically selected and assembled subroutines from a library based on symbolic instructions, marking a shift toward automated code linking. For 's 704 computer, introduced in 1954, the linking loader enabled the combination of relocatable object modules and library routines at load time, supporting by resolving addresses and external references dynamically. These loaders, among the first full-featured examples, facilitated the creation of subroutine libraries that could be shared across programs, significantly improving efficiency on vacuum-tube mainframes. The influence of mathematical subroutine libraries became prominent with the release of in 1957, designed for scientific on the IBM 704. 's system included a library of precompiled mathematical subroutines, such as those for (e.g., SINF) and absolute values (e.g., ABSF), stored in relocatable binary form on the master tape for easy incorporation into user programs via function calls. These routines, supporting fixed- and floating-point operations with up to eight decimal digits of precision, were passed arguments through registers or common storage and returned results accordingly, enabling complex numerical computations without rewriting basic algorithms. This standardization drew from earlier mathematical libraries but integrated them seamlessly into high-level code, promoting reusability in fields like physics and . Early challenges in these foundational libraries included manual assembly and a lack of , which hampered portability and reliability. On , subroutines required physical rewiring or switch settings for each invocation, making maintenance error-prone and time-consuming. Even with and early systems, programmers often had to hand-code and explicitly include subroutines in assembly listings, without uniform formats for relocation or symbol resolution, leading to redundant efforts and compatibility issues across machines. These limitations underscored the need for automated tools like linking loaders, setting the stage for more robust library systems.

Evolution

The evolution of computing libraries began in the 1960s and 1970s with the rise of high-level programming languages that facilitated modular through libraries and associated mechanisms like header files. The development of in 1972 at marked a pivotal advancement, as it introduced structured approaches to compiling code into reusable object files that could be archived into libraries, enabling efficient linking for Unix-based systems. Header files in C further supported this by allowing declarations of library functions to be shared across source files, promoting portability and reducing redundancy in early system programming. During this era, Unix environments relied primarily on static libraries, such as those for mathematical functions, which were integrated at to build robust utilities and operating system components. In the and , libraries advanced toward dynamic linking and object-oriented paradigms, enhancing runtime flexibility and application development efficiency. introduced dynamic-link libraries (DLLs) with in 1985, allowing code and resources to be shared across multiple applications at runtime, which reduced usage and simplified updates in the burgeoning . This built on earlier Unix concepts but adapted them for graphical user interfaces and broader commercial software. By the early , object-oriented class libraries emerged, exemplified by 's Foundation Classes (MFC), first released in 1992 with Microsoft C/C++ 7.0, which provided C++ wrappers for Windows APIs, streamlining GUI and event-driven programming through and encapsulation. These innovations shifted library design from mere code repositories to comprehensive frameworks that supported complex, reusable abstractions. The 2000s saw the proliferation of open-source ecosystems, democratizing library access and fostering collaborative development across platforms. The GNU Project's libraries, particularly the GNU C Library (glibc), evolved significantly during this period, integrating with distributions to provide standardized interfaces for system calls, threading, and internationalization, underpinning millions of open-source applications. Package managers like npm, introduced in 2010 for , revolutionized dependency management by enabling declarative installation of libraries from centralized registries, accelerating and reducing version conflicts in large-scale projects. Cross-platform standards, such as those refined in POSIX.1-2008 and emerging .NET frameworks, further promoted , allowing libraries to function seamlessly across systems, Windows, and virtual machines without extensive rewrites. Recent trends from the 2010s to 2025 have integrated libraries with and portable runtimes, addressing deployment challenges in distributed environments. Docker, launched in 2013, transformed library usage by encapsulating dependencies within lightweight containers, ensuring consistent runtime behavior across development, testing, and production while mitigating "works on my machine" issues through isolated library versions. This approach has influenced library design, with many now optimized for container-friendly formats that minimize image sizes and enhance security via layered builds. Concurrently, (Wasm) modules have emerged as a versatile library format, compiling languages like C++, , and Go into efficient, sandboxed binaries that run near-natively in browsers and setups, with advancements in the WebAssembly System Interface (WASI) by 2025 enabling secure, cross-platform library sharing beyond the web.

Types

Static Libraries

Static libraries, also referred to as archive libraries, consist of collections of precompiled object files bundled together into a single . On systems, these archives are created using the ar utility and conventionally named with a .a extension, such as libexample.a, where the lib prefix and .a suffix are standard conventions followed by the linker. On Windows platforms, static libraries use the .lib extension and are generated by tools like the librarian. During the compilation and linking phase, the linker processes a static by scanning its archive for object files that define symbols referenced by the program. Only the necessary object files are extracted and their is directly embedded into the final , resolving all dependencies at build time without leaving any unresolved external references. This results in a standalone binary that incorporates the library verbatim. The primary advantages of static libraries include the elimination of runtime dependencies, enabling to run on any compatible without requiring additional library installations or version matching, which simplifies deployment and enhances portability. Execution can also be marginally faster due to the absence of overhead and function . However, drawbacks include significantly larger sizes from full library code, potential code duplication across multiple programs using the same library, and the need to recompile all dependent applications whenever the library is updated or bug-fixed. A representative example is the GNU C library's math library, libm.a, which provides static implementations of mathematical functions such as sin(), cos(), and sqrt(). When a C program includes <math.h> and invokes these functions, the linker incorporates the relevant from libm.a into the executable, ensuring all arithmetic operations are self-contained. Unlike dynamic libraries, static libraries provide fixed code integration at , avoiding runtime flexibility but guaranteeing consistency.

Dynamic Libraries

Dynamic libraries, also known as dynamically linked libraries, are collections of and that are loaded into by the operating system's loader at program execution time, enabling multiple processes to share the same library instance for efficiency. This runtime loading contrasts with static libraries, which embed directly into the during compilation. A key feature of dynamic libraries is delayed binding, where symbol resolution—mapping function names to their actual addresses—occurs only when the code is first executed, rather than at load time, which reduces initial startup overhead through mechanisms like procedure linkage tables (PLTs). They also support versioned loading, allowing the system to select specific library versions (e.g., via version numbers in filenames) to match application requirements without recompilation. The primary advantages include smaller file sizes, as the code is not duplicated in each program, leading to reduced needs. efficiency is achieved by loading the library once into space, accessible by multiple applications simultaneously, which optimizes resource usage in multitasking environments. Updates to the library can be applied centrally without modifying or redistributing individual executables, facilitating maintenance and bug fixes across systems. However, dynamic libraries introduce challenges such as dependency issues, where programs may fail if required libraries are missing or incompatible with the system's versions. A notable disadvantage is "DLL Hell," a conflict arising when installing one application overwrites or replaces a version needed by another, causing unexpected failures due to mismatched entry points or interfaces. Additionally, runtime binding can impose a slight performance penalty, estimated at 5-15%, from generating and resolving symbols on demand. Examples of dynamic libraries include Windows DLL files, such as those implementing the (e.g., kernel32.dll), which are loaded explicitly or implicitly at runtime to provide system services. On Linux, shared object (.so) files like libpthread.so.0 serve similar purposes, often used for plugins that extend application functionality without rebuilding the core program.

Shared Libraries

Shared libraries, also known as dynamic shared objects (DSOs) in systems, are files containing and that can be loaded into memory once and mapped into the of multiple processes simultaneously, allowing concurrent use by different applications without duplication. These libraries typically have filenames ending in .so (shared object) on and similar systems, and they are designed to provide reusable functions, such as those in the , that multiple programs can access at runtime. The loading and unloading of are managed by the operating system's , which uses mechanisms like to track usage across . When a requires a , the linker loads it via functions such as dlopen(), increments a reference count for each dependent module, and performs necessary relocations to integrate it into the 's ; inter-process compatibility is ensured by read-only text segments while keeping data segments private per . Unloading occurs through dlclose(), which decrements the reference count, and the library is only removed from when the count reaches zero and no other dependencies remain, preventing premature deallocation. Shared libraries offer significant advantages in resource conservation, as a single instance in physical serves multiple processes, reducing overall RAM usage and disk space compared to embedding code in each . This also facilitates easier updates to library code without recompiling dependent applications, promoting efficiency in large-scale systems. However, they introduce disadvantages such as version conflicts, where incompatible changes in library versions can break applications (often termed "DLL hell" in Windows contexts, with analogous issues in Unix), requiring careful versioning schemes like SONAMEs to mitigate. Additionally, security risks arise from shared writable and segments, which can enable attacks if not protected by features like RELRO (relocation read-only). A prominent example is libc.so, the GNU C Library shared object, which provides essential functions like printf() and malloc() and is loaded once into memory to serve all C programs on a system, exemplifying how shared libraries conserve resources in everyday computing environments.

Object Libraries

Object libraries serve as an intermediate artifact in the software build process, consisting of collections of compiled object files—typically with extensions like .o on Unix-like systems or .obj on Windows—that remain unlinked and contain machine code modules derived from source files. These files are generated by compilers such as GCC or Clang after the assembly stage, preserving unresolved symbols and relocation information for subsequent linking. Unlike source code or fully linked executables, object libraries facilitate modular development by allowing separate compilation of individual modules without immediate resolution of external dependencies. In build pipelines, object libraries act as inputs to linkers and archivers, enabling the creation of static or dynamic libraries as well as executables. For instance, tools like the GNU archiver (ar) can package multiple object files into an archive file, which then serves as a unit for the linker to extract and incorporate only the necessary modules during final assembly. This approach supports large-scale projects by decoupling compilation from linking, allowing build systems such as Make or CMake to manage dependencies efficiently. In CMake, for example, an object library target compiles sources without producing a linkable artifact, permitting those objects to be reused across multiple downstream targets via generator expressions like $<TARGET_OBJECTS:libname>. A primary advantage of object libraries is support for incremental compilation, where only modified source files need recompilation, significantly reducing build times in expansive codebases compared to full recompilations. This also promotes and team collaboration, as developers can compile and share object modules independently before integration. However, a key disadvantage is that object libraries are not directly ; they require further processing by a linker to resolve symbols and generate runnable binaries, limiting their standalone utility. For example, the GNU Binutils ar tool can create an object library archive named libfoo.a from several object files using the command ar rcs libfoo.a file1.o file2.o file3.o, where r adds or replaces members, c ensures creation if absent, and s generates an index of symbols for accelerated linking. This archive then provides the unlinked object modules as input for subsequent linking steps.

Runtime Libraries

Runtime libraries are collections of low-level routines and functions that support the execution of programs by managing essential runtime operations, such as initialization, resource allocation, and error management, often tailored to specific compilers or platforms. In the context of C programming, the runtime library includes components like crt0, which serves as the startup code responsible for setting up the program's execution environment before invoking the main function. These libraries bridge the gap between compiled code and the underlying operating system, ensuring that programs can perform necessary tasks without direct hardware interaction. Key components of runtime libraries typically encompass startup and initialization code, which prepares the stack, initializes global variables, and handles program termination; standard input/output routines for file and console operations; memory allocation functions like malloc and free; and error handling mechanisms, including exception support for languages like C++. For instance, in GCC's libgcc, these include arithmetic operations, exception handling routines, and basic memory operations such as memcpy, all implemented to support operations not feasible inline. In Microsoft's C runtime library, similar features are provided through modules like vcruntime.lib for exception handling and the Universal CRT for memory management and I/O, enabling robust execution in multi-threaded environments. The primary importance of runtime libraries lies in their role in enhancing by abstracting platform-specific details, allowing programs to execute consistently across different operating systems and hardware architectures without extensive modifications. This simplifies cross-platform development, as the library handles variations in system calls and , thereby reducing the need for application-level adaptations. For example, by standardizing runtime behaviors, these libraries ensure that applications compiled on one environment can run reliably on another, promoting broader compatibility. A prominent example is the Java Runtime Environment (JRE), which includes libraries essential for supporting the (JVM) during program execution, such as those for garbage collection, threading, and security management. The JRE provides the necessary runtime components to load, verify, and execute , abstracting OS differences to enable "write once, run anywhere" portability across diverse platforms like Windows, , and macOS. This setup ensures that Java applications rely on the JRE's libraries for core execution needs, including memory allocation and exception propagation within the JVM.

Standard Libraries

Standard libraries in refer to the official collections of functions, types, macros, and modules that are specified and mandated by a programming language's , ensuring a consistent set of core functionalities across compliant implementations. These libraries form an integral part of the language specification, providing essential building blocks for tasks such as operations, data manipulation, and mathematical computations, without which the language would lack portability and . The , as defined in the ISO/IEC 9899 specification, exemplifies this concept through its inclusion of headers like <stdio.h> for stream-based input and output, <string.h> for string handling functions such as strlen and strcpy, and <math.h> for mathematical operations including sin, cos, and pow. This library has evolved with standard revisions; for instance, the C11 edition (ISO/IEC 9899:2011) introduced enhancements like improved support for Unicode multibyte characters and atomic operations in <stdatomic.h>, expanding coverage to concurrent programming needs, while the latest C23 edition (ISO/IEC 9899:2024, published October 2024) adds features such as a built-in bool type, bit-precise integer types, and improved attributes for better code annotation and diagnostics. Similarly, the , outlined in ISO/IEC 14882, builds upon the C library while adding object-oriented and generic programming support, such as the (STL) components for containers (e.g., std::vector) and algorithms (e.g., std::sort), with the C++17 edition (ISO/IEC 14882:2017) incorporating features like the filesystem library in <filesystem> for directory and file operations, and the current C++23 edition (ISO/IEC 14882:2024, published October 2024) introducing modules for better encapsulation, enhanced coroutines, and improvements to ranges and concepts. In dynamically typed languages like Python, the comprises a suite of built-in modules that interface with the operating system and provide standardized solutions for common tasks, as specified in the Python language reference (version 3.14 as of October 2025). Key examples include the os module for platform-independent path manipulations and interactions, and the sys module for accessing interpreter-specific variables and command-line arguments. These modules cover areas such as file I/O via io, mathematical functions in math, and string processing with built-in methods, ensuring developers have immediate access to robust, cross-platform tools. The primary role of standard libraries is to guarantee , allowing code written for one compliant or interpreter to function predictably on another, while establishing a baseline of features that promote code reusability and reduce development overhead. By mandating these implementations, language standards foster a where baseline functionality is uniform, though actual runtime support may vary by platform.

Specialized Libraries

Class libraries represent collections of object-oriented classes, interfaces, and other types designed to provide reusable components for . In the .NET ecosystem, the (FCL) serves as a primary example, offering a comprehensive set of namespaces and types that encapsulate system functionality, including data types, interfaces, and utilities for tasks such as , networking, and . These libraries promote modularity by allowing developers to assemble applications from pre-built, extensible components, reducing redundancy and enhancing maintainability through and polymorphism. Remote libraries facilitate by enabling communication between components across different machines or processes, often through generated stubs that abstract network interactions. In systems like CORBA (), Interface Definition Language (IDL) files define remote object interfaces, from which client and server stubs are automatically generated to handle method invocations as if they were local calls, managing marshaling, location transparency, and error handling. Similarly, (RMI) employs stubs as proxy objects that serialize parameters and forward requests to remote servers, supporting object-oriented features like polymorphism in distributed environments without requiring explicit socket programming. These libraries are essential for building scalable, heterogeneous systems where services are invoked remotely, such as in enterprise applications or architectures. Code generation libraries automate the creation of during the build process, targeting specific domains like or protocol implementation to streamline development. (ANother Tool for Language Recognition), a prominent parser generator, takes grammar specifications in files (e.g., .g4 format) and produces lexer and parser code in languages like , C++, or Python at , enabling efficient processing of structured inputs such as programming languages or configuration files. This approach ensures high performance by generating tailored, recursive-descent parsers that can construct abstract syntax trees, avoiding the need for manual coding of and syntax rules. Beyond these, specialized libraries include variants, prevalent in C++ for template-heavy implementations, where all code resides in header files to allow the to instantiate templates inline without separate compilation or linking steps. This design minimizes deployment complexity and optimizes for , as seen in many components of the Boost C++ Libraries, which distribute for user compilation while keeping template-based modules to leverage C++'s fully. Source-based libraries like Boost extend this by providing portable, peer-reviewed code that users build from source, ensuring compatibility across platforms and without precompiled binaries.

Linking

Static Linking

Static linking is a process in which the linker incorporates the necessary code from static libraries directly into the final executable file during the build phase, resulting in a self-contained program that does not rely on external libraries at runtime. This approach ensures that all required library functions and data are resolved and embedded at compile time, producing a larger but standalone binary. The linker, such as the GNU linker (ld), combines multiple input object files—generated from compilation—with static libraries (typically in .a archive format) to form a single executable. During this phase, external references in the object files are matched to their corresponding definitions within the static libraries, a process known as resolution. The linker scans the symbol tables of the inputs to identify undefined symbols and locates their implementations, ensuring all dependencies are satisfied before generating the output. The linking process involves several key steps: first, the linker processes the command-line inputs in order, starting with the program's object files and then the specified static libraries via options like -l. It scans each static library archive sequentially, examining its internal object files to find those that provide definitions for currently unresolved symbols. Only the necessary object files are extracted from the archive and incorporated, avoiding inclusion of unused to optimize the executable size; this selective extraction repeats as new undefined symbols arise from previously pulled objects. Dependencies between libraries are resolved by iterating through the archives multiple times if required, often using constructs like --start-group and --end-group to circular references. Once all symbols are resolved, the linker merges the , data, and other sections from the selected objects into a cohesive layout. A common example of invoking static linking is with the GCC compiler using the -static flag, as in gcc -static main.c -o program -lm, which directs the linker to embed the math library (libm.a) and other dependencies directly into the resulting program . This contrasts with dynamic linking, where library resolution occurs at runtime.

Dynamic Linking

Dynamic linking, also referred to as shared linking, is a mechanism in which the symbols referenced by an executable are resolved at load time or during execution, rather than being fully integrated at . This process begins when the operating system's loader identifies a dynamically linked and invokes a runtime linker, such as ld.so on systems, to map the necessary shared libraries into the process's . The runtime linker recursively loads dependencies listed in the 's dynamic section (e.g., via DT_NEEDED entries in ELF files), applies initial relocations to itself, and prepares stubs—such as the Procedure Linkage Table (PLT)—for deferred symbol resolution. This approach enables memory sharing among multiple processes and facilitates updates to libraries without recompiling applications. Dynamic linking supports two primary modes: load-time (eager) binding and run-time (lazy) binding. In eager binding, all external s are resolved immediately upon program startup, often enforced by environment variables like LD_BIND_NOW on or compiler flags such as -z now, ensuring complete resolution before execution proceeds but potentially increasing startup latency. Lazy binding, the default in many systems, defers resolution until a symbol is first invoked; for instance, a PLT stub initially redirects calls to the runtime linker, which then updates the Global Offset Table (GOT) with the actual function address for subsequent direct calls, optimizing initial load times especially for large applications with unused library functions. Unlike static linking, which embeds code directly into the at build time, dynamic linking promotes efficiency through usage across processes. On systems, explicit control over run-time linking is provided by the API, including functions like dlopen() to load a shared object (e.g., a .so file) and return a , and dlsym() to retrieve the address of a specific within that object. These tools support flags such as RTLD_LAZY for deferred binding or RTLD_NOW for immediate resolution, allowing programs to load libraries on demand without prior knowledge at . Similarly, on Windows, run-time dynamic linking uses LoadLibrary() (or LoadLibraryEx()) to load a DLL into the process and increment its reference count, followed by GetProcAddress() to obtain function pointers, enabling flexible module loading independent of import libraries used in load-time scenarios. A common application of dynamic linking is in plugin architectures, where an application uses dlopen() to load extension modules (e.g., .so files) at runtime based on user input or configuration, resolving their symbols via dlsym() to extend functionality without requiring the core program to be rebuilt. This is exemplified in systems like web browsers loading renderer plugins or media players incorporating codec libraries, promoting and reducing binary size. The reference count maintained by the runtime linker ensures libraries remain loaded only as long as needed, with unloading via dlclose() on Unix or when the count reaches zero on Windows.

Relocation

Relocation Process

In computing, relocation is the process of modifying the addresses embedded in the machine code and data of a relocatable object, such as a dynamic library, to account for its actual loading position in memory. This adjustment ensures that references to symbols—such as functions, variables, or other code segments—resolve correctly, regardless of where the library is placed by the operating system's loader. For dynamic libraries, relocation typically occurs at load time, performed by the runtime linker (also known as the dynamic loader), which processes relocation entries stored in the library's executable format, such as the Executable and Linkable Format (ELF) used in Unix-like systems. The relocation process begins after the dynamic linker has loaded the library's segments into memory and determined its base address, which may vary across executions to enhance security through (ASLR). The linker then examines the relocation sections, such as .rel.dyn or .rela.dyn in ELF files, which contain an array of relocation entries. Each entry specifies an offset within the library (where the adjustment is needed), a type indicating the relocation kind (e.g., absolute address update or PC-relative adjustment), and an associated symbol from the library's . For instance, in ELF, a Elf32_Rel entry includes r_offset (the byte offset or virtual address to patch) and r_info (encoding the symbol index and relocation type), while Elf32_Rela variants add an explicit r_addend constant. The linker computes the target value by adding the symbol's resolved address (obtained via symbol lookup), any addend, and the library's base address, then stores the result at the specified offset—effectively patching the code or data in place. To handle external references efficiently, dynamic libraries employ indirection mechanisms like the Global Offset Table (GOT) for data symbols and the Procedure Linkage Table (PLT) for function calls. The GOT is a writable array of pointers initialized during relocation; the linker updates its entries with the actual addresses of global variables or data from other modules, allowing the library's code to access them indirectly without further patching. Similarly, the PLT serves as a trampoline for unresolved function calls: initial entries point to the dynamic linker, which performs lazy binding—resolving and updating the PLT only on the first invocation of the function—while subsequent calls jump directly to the target. This lazy approach defers non-essential relocations until needed, reducing startup overhead, though immediate binding (all relocations at load time) can be enforced for debugging or security. In ELF-based systems, symbol lookup during relocation prioritizes the main executable, followed by dependencies in load order, respecting visibility rules like global (search all objects) or local (within the same dependency group). Relocation types vary by ; for example, on x86, R_386_32 adds a 32-bit absolute address, while R_386_PC32 computes a PC-relative offset for branches. Consecutive relocations at the same offset are composed into a single adjustment to avoid intermediate computations. Post-relocation, the linker executes any initialization routines (e.g., in the .init section) before transferring control to the program. This process enables dynamic libraries to be shared across processes without duplication, but it introduces overhead from load-time computations and potential vulnerabilities if writable sections like the GOT are exploited. Modern systems mitigate this via techniques like RELRO (Relocation Read-Only), which protects relocated sections after processing.

Position-Independent Code

Position-Independent Code (PIC) is a programming technique that enables executable code to operate correctly regardless of its absolute memory location, relying on relative addressing modes and runtime-resolved references rather than fixed addresses. In formats like , PIC achieves this through mechanisms such as the (GOT), which stores absolute addresses for data accesses, and the Procedure Linkage Table (PLT), which handles indirect jumps to external functions, allowing the code itself to remain unmodified and relocatable at load time. This approach ensures that shared libraries can be mapped to arbitrary addresses without requiring per-process relocations of the text segment, preserving its read-only and sharable nature. The primary advantages of PIC include enhanced security through compatibility with Address Space Layout Randomization (ASLR), which randomizes load addresses to thwart memory-based exploits, and improved efficiency in library sharing across multiple processes by eliminating the need for private copies or runtime text relocations. It also reduces and swap usage, as the shared text segment avoids duplication. However, PIC incurs a slight performance overhead due to the added indirections—such as extra instructions for GOT/PLT accesses—which can make data loads and function calls marginally slower compared to position-dependent code, particularly in performance-critical applications. PIC is implemented via compiler options, such as the -fPIC flag in GCC, which generates code without Global Offset Table size limitations and defines macros like __PIC__ to 2 for conditional compilation. This flag is essential for building shared libraries on platforms supporting dynamic linking, as it ensures compatibility with the runtime loader. For instance, most modern dynamic libraries in systems, including those in and other standard distributions, are compiled as PIC to facilitate secure and efficient deployment.

Platform Conventions

Unix-like Systems

In Unix-like systems, libraries follow standardized naming conventions to facilitate identification and linking. Static libraries are typically archived in files with the extension .a, prefixed by lib, such as libexample.a, which bundles object files for inclusion during the linking phase of compilation. Dynamic libraries, known as shared objects, use the .so extension, also prefixed by lib, and include version information in the filename to manage compatibility, for example libexample.so.1.2.3, where the numbers represent , and release versions, respectively. This versioning scheme, supported by tools like Libtool, allows multiple versions to coexist, enabling backward compatibility while introducing new interfaces. Several command-line tools are integral to managing libraries in Unix-like environments. The ar utility creates and maintains static library archives by combining object files into a single .a file, serving as a binary utility for subroutine libraries. The GNU linker ld resolves symbols and combines object files, static libraries, and shared objects into executables or further libraries, supporting options for both static and dynamic linking. For inspecting dependencies, the ldd command lists the shared libraries required by an executable or another shared object, revealing the dynamic linker's resolution paths and versions at runtime. These conventions align with standards, which promote portability across systems by defining a core set of system interfaces, including standard libraries like the C library (libc), ensuring applications can be compiled and run consistently without platform-specific modifications. compliance, as outlined in IEEE 1003.1, emphasizes header files, function prototypes, and behaviors for library functions to enable source-level portability. A representative example of library organization is the /usr/lib directory, which holds architecture-dependent libraries for user-installed applications, often structured with subdirectories for specific architectures (e.g., /usr/lib/x86_64-linux-gnu) to separate 32-bit and 64-bit variants, adhering to the (FHS). Essential system libraries may reside in /lib, but /usr/lib typically contains development libraries and shared objects for broader software ecosystems.

macOS

In macOS, libraries are primarily formatted using the executable file format, which serves as the native binary structure for , dynamic libraries, and static archives. Dynamic libraries, known as .dylib files, are shared libraries that are loaded at runtime by the , allowing multiple applications to share the same code in memory and reducing redundancy. Static libraries, on the other hand, use the .a extension and consist of archived object files that are linked directly into the executable during compilation, embedding the library code permanently into the application binary. Naming conventions for macOS libraries follow a structured to facilitate identification and loading. Dynamic libraries typically adopt the form lib<library_name>.dylib, such as libz.dylib for the zlib compression library, and are installed in system directories like /usr/lib or /System/[Library](/page/Library)/Frameworks. For higher-level abstractions, macOS employs framework bundles, which package dynamic libraries (.dylib) along with headers, resources, and metadata into a (e.g., Foundation.framework), promoting modularity and through umbrella frameworks that encompass related subframeworks. These bundles are located in /System/[Library](/page/Library)/Frameworks for system-provided libraries, enabling developers to link against comprehensive APIs without managing individual .dylib files directly. Key tools support the inspection, loading, and management of these libraries. The otool utility examines binaries, revealing dependencies (via otool -L), symbols, and sections, which aids in linking issues or verifying library integrity. The , dyld (located at /usr/lib/dyld), handles runtime loading of .dylib files, resolving symbols and enforcing compatibility versions to prevent mismatches between library revisions. Developers can interact with dyld programmatically using functions from /usr/include/dlfcn.h, such as dlopen for loading libraries and dlsym for symbol resolution. A distinctive feature of macOS libraries is support for universal binaries, which encapsulate multiple architectures (e.g., x86_64 for and arm64 for ) within a single file, enabling seamless execution across hardware without recompilation. Both .dylib and .a libraries can be built as universal binaries using the lipo tool to merge architecture-specific variants, ensuring and simplifying distribution for developers targeting diverse Mac systems. This multi-architecture capability stems from macOS's evolution to support transitions like the shift to , with verification possible via lipo -info or otool -f.

Windows

In Windows, libraries follow the (PE) format, which is based on the Common Object File Format (COFF), enabling both executable files and shared libraries to share a common structure for loading and execution. Dynamic libraries are distributed as files with the .dll extension, containing executable code, data, and resources that can be loaded at runtime by applications or other libraries. Static libraries and import libraries use the .lib extension; static .lib files archive for direct linking into executables, while import .lib files provide stub information for resolving references to functions exported by DLLs during the build process. DLL naming conventions typically append ".dll" to the library name, such as "example.dll", to indicate its dynamic nature and facilitate system identification during loading. To mitigate DLL hell—conflicts from version mismatches—Windows supports side-by-side () assemblies, where DLLs are packaged with XML manifests that specify assembly identity, including name, version, public key token, and dependencies, allowing multiple versions to coexist without overwriting system files. These manifests are embedded in the DLL or provided externally and are used by the application verifier and fusion loader to bind to the correct assembly version at runtime. The Microsoft Visual C++ (MSVC) linker, link.exe, is the primary tool for creating both static libraries and DLLs by combining object files (.obj) and libraries into PE-format outputs, supporting options for export definitions and manifest generation. For analysis, dumpbin.exe examines PE/COFF files, displaying details such as exports, imports, sections, and dependencies in DLLs and .lib files, aiding developers in linking issues or verifying binary contents. A distinctive feature of Windows libraries, particularly those implementing (COM) interfaces, is self-registration via the registry; DLLs expose a DllRegisterServer function that, when invoked by regsvr32.exe, adds entries under HKEY_CLASSES_ROOT with class IDs (CLSIDs), paths to the DLL, and threading models to enable discovery and instantiation by COM clients. This registry-based mechanism contrasts with systems' reliance on file paths and environment variables, providing centralized metadata for binary reuse across applications.

References

  1. https://www.sciencedirect.com/topics/computer-science/software-library
  2. https://docs.oracle.com/cd/E19957-01/806-3593/4_libraries.html
  3. https://www.sciencedirect.com/science/article/pii/B9780124201583000101
  4. https://www.cs.ucdavis.edu/~devanbu/s-temp.pdf
  5. https://www.learncpp.com/cpp-tutorial/a1-static-and-dynamic-libraries/
  6. https://www.geeksforgeeks.org/operating-systems/static-vs-dynamic-libraries/
  7. https://cio-wiki.org/wiki/Software_Development_Kit_%28SDK%29
  8. https://users.ece.utexas.edu/~mcdermot/arch/0LD/lectures_2009/Lecture_17.pdf
  9. https://ieeexplore.ieee.org/document/310921/
  10. https://www.cs.hunter.cuny.edu/~sweiss/resources/software_libraries.pdf
  11. https://commons.apache.org/math/
  12. https://textbooks.cs.ksu.edu/cc410/ii-gui/14-libraries/index.print.html
  13. https://www.cs.cornell.edu/courses/cs5150/2019sp/slides/18-reuse.pdf
  14. https://www.utc.edu/document/72201
  15. https://textbooks.cs.ksu.edu/cc410/ii-gui/14-libraries/02-software-libraries/index.html
  16. https://diveintosystems.cs.swarthmore.edu/book/C5-Arch/hist.html
  17. https://www.ebsco.com/research-starters/computer-science/univac-computer
  18. https://innovation.world/invention/a-0-system/
  19. http://www.staroceans.org/e-book/LinkersAndLoaders.pdf
  20. https://archive.computerhistory.org/resources/text/Fortran/102649787.05.01.acc.pdf
  21. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html
  22. https://cscie26.dce.harvard.edu/~dce-lib113/reference/c/c_history.html
  23. https://www.cs.dartmouth.edu/sergey/cs108/ABI/UlrichDrepper-How-To-Write-Shared-Libraries.pdf
  24. https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-libraries
  25. https://learn.microsoft.com/en-us/cpp/mfc/mfc-desktop-applications?view=msvc-170
  26. https://www.gnu.org/software/libc/
  27. https://www.docker.com/resources/what-container/
  28. https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
  29. https://learn.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-static-library-cpp?view=msvc-170
  30. https://www.cs.arizona.edu/sites/default/files/TR04-02.pdf
  31. https://docs.oracle.com/cd/E36784_01/html/E36857/chapter1-6.html
  32. https://cseweb.ucsd.edu/~gbournou/CSE131/the_inside_story_on_shared_libraries_and_dynamic_loading.pdf
  33. https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/june/windows-xp-escape-from-dll-hell-with-custom-debugging-and-instrumentation-tools-and-utilities
  34. https://developer.ibm.com/tutorials/l-dynamic-libraries/
  35. https://man7.org/linux/man-pages/man3/dlopen.3.html
  36. https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter4-1/index.html
  37. https://cmake.org/cmake/help/latest/command/add_library.html
  38. http://csapp.cs.cmu.edu/2e/ch7-preview.pdf
  39. https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.0?topic=library-compiling-linking
  40. https://sourceware.org/binutils/docs/binutils/ar.html
  41. https://stackoverflow.com/questions/14636916/why-use-object-files-in-c
  42. https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-170
  43. https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
  44. https://www.sciencedirect.com/topics/computer-science/runtime-library
  45. https://www.sciencedirect.com/topics/computer-science/runtime-environment
  46. https://docs.oracle.com/en/database/oracle/oracle-database/19/adxdk/getting-started-with-XDK-for-C.html
  47. https://www.ituonline.com/tech-definitions/what-is-a-runtime-library/
  48. https://aws.amazon.com/what-is/java-runtime-environment/
  49. https://www.ibm.com/think/topics/jre
  50. https://www.iso.org/standard/57853.html
  51. https://www.iso.org/standard/68564.html
  52. https://www.iso.org/standard/82075.html
  53. https://www.iso.org/standard/82700.html
  54. https://docs.python.org/3/library/index.html
  55. https://docs.python.org/3/library/intro.html
  56. https://learn.microsoft.com/en-us/dotnet/standard/class-libraries
  57. https://learn.microsoft.com/en-us/dotnet/standard/class-library-overview
  58. https://www.omg.org/spec/CORBA/3.0/About-CORBA
  59. https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/index.html
  60. https://www.antlr.org/
  61. https://cfd.university/learn/how-to-compile-write-and-use-cfd-libraries-in-c/understanding-static-dynamic-and-header-only-c-libraries/
  62. https://www.boost.org/
  63. https://sourceware.org/binutils/docs/ld/
  64. https://man7.org/linux/man-pages/man1/ld.1.html
  65. https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
  66. https://man7.org/linux/man-pages/man8/ld.so.8.html
  67. https://lwn.net/Articles/961117/
  68. https://man7.org/linux/man-pages/man3/dlsym.3.html
  69. https://learn.microsoft.com/en-us/windows/win32/dlls/about-dynamic-link-libraries
  70. https://refspecs.linuxbase.org/elf/gabi4+/ch4.reloc.html
  71. https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter3-29.html
  72. https://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries
  73. https://refspecs.linuxfoundation.org/elf/elf.pdf
  74. https://docs.oracle.com/cd/E26505_01/html/E26506/glmqp.html
  75. https://www.redhat.com/en/blog/position-independent-executables-pie
  76. https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
  77. https://linux.die.net/man/1/ar
  78. https://sourceware.org/binutils/docs/ld/VERSION.html
  79. https://www.gnu.org/software/libtool/manual/html_node/Versioning.html
  80. https://linux.die.net/man/1/ld
  81. https://man7.org/linux/man-pages/man1/ldd.1.html
  82. https://pubs.opengroup.org/onlinepubs/9699919799/
  83. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html
  84. https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
  85. https://developer.apple.com/library/archive/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html
  86. https://developer.apple.com/forums/thread/715385
  87. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html
  88. https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html
  89. https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary
  90. https://learn.microsoft.com/en-us/windows/win32/debug/pe-format
  91. https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/february/inside-windows-win32-portable-executable-file-format-in-detail
  92. https://learn.microsoft.com/en-us/cpp/build/reference/working-with-import-libraries-and-export-files?view=msvc-170
  93. https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-creation
  94. https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-assemblies-and-dlls
  95. https://learn.microsoft.com/en-us/windows/win32/sbscs/about-side-by-side-assemblies-
  96. https://learn.microsoft.com/en-us/windows/win32/sbscs/assembly-manifests
  97. https://learn.microsoft.com/en-us/windows/win32/sbscs/guidelines-for-creating-side-by-side-assemblies
  98. https://learn.microsoft.com/en-us/cpp/build/reference/linker-options?view=msvc-170
  99. https://learn.microsoft.com/en-us/cpp/build/reference/dumpbin-reference?view=msvc-170
  100. https://learn.microsoft.com/en-us/cpp/build/reference/dumpbin-options?view=msvc-170
  101. https://learn.microsoft.com/en-us/windows/win32/com/registering-com-servers
  102. https://learn.microsoft.com/en-us/windows/win32/com/self-registration
  103. https://learn.microsoft.com/en-us/windows/win32/com/registering-com-applications
Add your contribution
Related Hubs
User Avatar
No comments yet.