Library (computer)
libvorbisfile.so to play an Ogg Vorbis file.In computing, a library or, called by language defect, library (from English library) is a set of functional implementations, coded in a programming language, which provides a well-defined interface to the functionality being called.
Unlike an executable program, the behavior that a library implements is not expected to be used autonomously (a program does: it has a main entry point), but rather is intended to be used by other programs, independent and from each other. simultaneously. On the other hand, the behavior of a library need not be too different from what might be specified in a program. Furthermore, some libraries may require others to function, since the behavior they define refines, or alters, the behavior of the original library; or makes it available for another technology or programming language.
Libraries can be linked to a program (or to another library) at different points in development or execution, depending on the type of link you want to establish, as detailed in the "Types" section.;.
Most modern operating systems provide libraries that implement system services. In this way, these services have become a "raw material" that any modern application expects the operating system to offer. As such, most of the code used by modern applications is provided in these libraries.
Note on terminology
Usually the term library is used to refer to a library, due to the similarity with the original English library. Both words, «library» and «bookstore», are correct according to the definitions (library, librería) of the RAE. Notwithstanding the foregoing, considering a literal translation, the correct meaning would be library, since the English term for “bookstore” is bookstore or book shop (literally: "book store"), or bookshelf (shelf or furniture to store books, bookcase or bookcase). A more direct and literal translation than "bookstore" would be the term: "bookseller". It is also common to refer to it with the word of Anglo-Saxon origin toolkit (set, equipment, briefcase, box, case, set (kit) of tools).
History
Early library-like programming concepts attempted to separate data definitions from program implementation. The COMPOOL (Communication Pool) concept was popularized by JOVIAL in 1959, although he borrowed the idea from the software of the large SAGE systems. Following the computer science principles of separation of problems (isolating small problems that are easy to address) and hiding information, "the purpose of COMPOOL is to allow the exchange of system data between several programs, providing a centralized description of them" (Wexelblat 1981:369).
COBOL included a primitive library system in 1959 (Wexelblat 1981:274), but Jean Sammet described them in retrospect as insufficient library resources (Wexelblat 1981: 258).
Another of the great contributions to the modern concept of the library was the innovation of the FORTRAN applet. These can be compiled independently of each other, but the compiler lacks a linker, so type checking between subprograms is impossible (Wilson et. al. 1988:126).
Finally, we should talk about the influence that Simula 67 had on the concept of 'library'. Simula is the first object-oriented programming language, and its classes are almost identical to the current concept used in Java, C++, and C#. Simula's class concept was also the origin of the package in Ada and the module of Modula-2 (Wilson et. al. 1988:52). Despite being developed in 1965, Simula classes could be included in library files and added at compile time (Wexelblat 1981:716).
Types
Static Libraries
Historically, libraries could only be static. A static library, also known as archive, is a container file with various object code files packed inside, which in the linking process, during compilation, will be copied and relocated (if necessary).) in the final executable file, along with the rest of the object code files. This process, and the executable file, is known as a static build of the target application. In this case, the library simply acts as a container for object code files that are no different (other than semantically) from the intermediate object files produced during the previous stage of program compilation. In the static construction of compiled files, addresses of assembled subroutines are resolved at compile time (more specifically, at the linking stage), so references to library subroutines are resolved statically, in the same way as references to any other function of the program. Thus, the real address, references for jumps, and other routine calls are stored in a relative or symbolic address.
The linker resolves all unresolved addresses by converting them to fixed or relocatable addresses (from a common base) by loading all code (including libraries) into memory locations at run time. This linking process can take even longer than the compilation process, and must be done every time one of the modules is recompiled.
A linker can work on specific types of object files, and therefore requires specific (compatible) types of libraries. Object files recompiled into a library can be easily distributed and used. A client, be it a program or another library, accesses an object library by referencing it by name only. The linking process resolves references by looking in the libraries in the given order. In general, it is not considered an error if a name can be found multiple times in a given set of libraries.
Dynamic Libraries
dynamic, dynamically linked, or dynamic-linked libraries are files that contain object code constructed independently of their location from in such a way that they are prepared to be able to be requested and loaded at execution time by any program, instead of having to be linked, previously, at compile time. Therefore, they must be available as independent files to the executable program (generally in system directories). In the linking process (at compile time) an executable file is generated with annotations of what dynamic libraries it requires (but not where to find them), and "sketch" functions that take care of delegating the function call to the dynamic loader (or dynamic-loader) (on Linux, ld.so). In the rest of the program, the library function calls are replaced by a linker-generated sketch function call.
On the other hand, when the running application requires access to routines stored in a dynamic library, and executes the stub function, the dynamic link loader can replace this call with the actual dynamic library function, loading it in memory if it wasn't already, and mapping the pages of it to the memory space of the program's process.
On some operating systems it can be decided whether a library should be available immediately or only when a function of it is referenced. If the latter is decided, a phenomenon called load delay will appear, derived from having to load the library from secondary memory, if it were not already in memory, and adjusting it to the address space of the program against the which is linked
Advantages of dynamic linking over static linking are that not only code reuse is allowed, but also physical space: the same shared library file can be used by several programs without them copying its content within them. This can be quite a bit of space, depending on the number of libraries a program requires. In addition, main memory (RAM) can be reused for programs that use the same library (for example, Qt libraries may need to be loaded only once for all programs that use them).
On the other hand, the biggest drawback is the increase in loading time (due to having to search for the library file, load it and relocate the calls in the program) and the increase in indirection when calling library functions.
Dynamic linking, by its nature, is limited only by software licenses.
The technology that allows you to link libraries dynamically is very useful for building plugins, especially when some libraries can be replaced by others with a similar interface, but different functionality. It can be said that a software has a "plugin architecture" if you use libraries with basic functionality with the intention that they can be superseded. However, the use of dynamically linked libraries in an application's architecture does not necessarily mean that they can be superseded.
Dynamic linking was originally developed in the Multics operating systems starting in 1964. It was a feature of the MTS (Michigan Terminal System), built in the late the 60s.
In different operating systems they take different names, for example:
- In Microsoft Windows: DLL (dynamic-link library)
- In Linux: shared-objects
- On Mac OS: "dynamic Bibles" (dylib(s)
Relocation
One of the problems that the loader must manage is that the actual location of the library data cannot be known until the executable and all dynamic libraries that have been linked to it have been loaded into memory. That's because memory locations depend on which dynamic libraries have been loaded. It is not possible to depend on the absolute address of the data in the executable, or even in the library, since conflicts could occur between the different libraries: if two of them used the same addresses or their addresses overlapped, it would be impossible to use both in the same program.
However, in practice, on many systems the libraries do not change frequently. Thus, it is possible to calculate a probable load address for each shared library on the system before it is used, and store that information in libraries and executables. If every library that is loaded is treated like this, then each of them will be loaded at default addresses, which speeds up the dynamic link process. This optimization is known as Prebinding on Mac OS X and Prelinking on Linux.
Disadvantages of this technique are the time required to precompute addresses each time the shared libraries change, the inability to use techniques such as address space randomization, and the consumption of virtual address space (a problem which is mitigated by the use of 64-bit architectures, at least currently).
An old method was to examine the program at load time. Once all the libraries have been loaded, all references to data in the libraries are replaced with pointers to appropriate memory locations. In Windows 3.1 (and some embedded systems like Texas Instruments calculators), references were handled as linked lists, allowing for easy enumeration and replacement. Now, most dynamic libraries bind a symbol table with blank addresses into the program at compile time. All references to code or data in the library pass through this table. At load time, the table is modified with the address of the data/code by the linker. This process is slow and significantly affects the speed of programs that continually call other programs, such as some shell scripts.
The library contains a jump table of all the methods it contains, called entry points. Calls within the library "jump through" the table, looking up the location of the code in memory, and then requesting it. These requests involve an extra effort, but the delay is usually so small as to be negligible.
Library localization at run time
Dynamic linkers/loaders have very broad functionality. Some depend on explicit paths to libraries stored in executables. Any changes to the filesystem design or nomenclature will cause these systems to fail. Usually only the name of the library (not the path) is stored in the executable, with the operating system providing the mechanism to find the library on disk using certain algorithms.
One of the biggest disadvantages of dynamic linking is that the proper functioning of executables depends on a number of libraries stored in isolation. If the library is deleted, moved, or renamed, or if an incompatible version of the DLL is copied to a location earlier in the search path, the executable will fail to load. On Windows this is known as DLL hell.
Unix Systems
Most Unix-like systems have a "search path" A that specifies the file system directories in which to search for dynamic libraries. On some systems, the default path is specified in a configuration file; in others, it is prefixed (hard coded) in the dynamic loader. Some executable file formats may specify additional directories in which to search for the libraries of a given program. This can usually be overridden by an environment variable, although it is disabled for programs that have setuid or setgid, so that the user cannot force that program to execute arbitrary code. It is recommended that library developers put their dynamic libraries in directories that are in the default search path. On the contrary, this can make the installation of new libraries problematic, since it makes those directories grow a lot, making it complicated.
Dynamic loading
Remote Libraries
Another solution to the library problem is to use completely separate executables (often a lightweight version) and call them via remote procedure (RPC) over the network to another computer or computer. This approach maximizes operating system reuse: the code needed to support the library is the same as the code used to provide the application with support and security for any other program. Additionally, these systems will not require that the library be recorded on the same machine, being able to redirect the request through the network.
However, such an approach implies that each call to the library will require a large amount of overhead. RPC calls are much more expensive than procedure calls on the machine itself. This approach is commonly used in RPC-intensive distributed architectures, in client-server systems, and in applications such as Enterprise JavaBeans.