💾 Archived View for yujiri.xyz › software › guide › libraries.gmi captured on 2023-01-29 at 04:46:09. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Learn programming for good instead of profit
A library is a bunch of code that's expected to be useful as part of many different programs, and so it's developed separately from any specific program. Programs usually depend on a few libraries. For example, there's a library called libpng ('lib' stands for library) which contains code for dealing with PNG images. Almost any program that displays or manipulates PNG images probably uses libpng.
Also, each programming language has one library called the *standard library* of that language (or just 'stdlib'), which contains code considered so essential that it's installed as part the same package as the language's compiler or interpreter itself. A standard library typically contains code for doing things like making syscalls and dealing with common data structures and file formats.
There are two different ways programs can use libraries: static linking and dynamic linking. In static linking, the program and the library are compiled together, producing just one executable file that contains machine code for both the program itself and whatever parts of the library it needs. In theory, a statically linked executable doesn't need any other files present to run: you can copy just that one file onto a computer and the program will work. (There are many caveats to this even with static linking, such as different processor architectures, different operating systems, or depending on things other than libraries, like image files and configuration files.)
In dynamic linking, on the other hand, the library is compiled separately, into something called a *shared object* file (on Unix) or DLL (dynamically loaded library, on Windows), and installed into a separate folder on your cmoputer. Then the program is compiled, without the library, into a dynamically linked executable that contains information about what libraries it needs. When the operating system runs a dynamically linked executable, it reads that information, finds the installed libraries, and links them together at run-time. (If it can't find the libraries, the program won't work.)
One reason dynamic linking is popular is to save space. If you have a library that (like libpng) is gonna be used by a dozen different programs, they can all share one copy of libpng. If all the programs were statically linked, they'd all have their own copies of libpng, embedded inside their executables. In practice it's more complex than that because most programs only use part of the library, and by static linking they include only the parts they use; while with dynamic linking you have to have the entire library installed even if all your programs only use part of its functionality. Dynamic linking does generally save space though.
Another and perhaps more compelling reason to use dynamic linking is that it means you can update a library just once and all your programs will be using the updated version. If your programs were statically linked, you would need to update all the programs that use it in order to use the new version of the library.
The downside of dynamic linking is basically just that it's a lot more complicated; there's more things that can go wrong with installing a dynamically linked program. If you're installing it from your distribution's package manager then it'll handle these things for you, but if not, it's going to be a massive pain to hunt down and compile the libraries yourself. Even if the library is already installed, it might be too old or too new a version of the library for the program to work with it.
Also, most compiled languages don't actually support dynamic linking, or support it in a very restricted way. C and C++ are really the only languages where dynamic linking is a thing. Modern languages are designed for the program and all its dependencies (except ones written in C or C++) to be compiled together.