Static and Dynamic LibrariesEdit
Libraries come in two forms, either in source form or in compiled/binary form. Libraries in source-form must first be compiled before they can be included in another project. This will transform the libraries' cpp-files into a lib-file. If a program must be recompiled to run with a new version of a library, but does not need any further changes, the library is said to be source compatible. If a program does not need to be modified and recompiled to use a new version of a library, the library is then classified as being binary compatible.
Advantages of using static binaries:
- Simplification of program distribution (fewer files).
- Code simplification (no version checks as required in dynamic libraries).
- Will only compile the code that is used.
Disadvantages of using static binaries:
- Waste of resources: Generates larger binaries, since the library is compiled into the executable. Wastes memory as the library cannot be shared (in memory) between processes (depending on the operating system).
- Program will not benefit from bug fixes or extensions in the libraries without being recompiled.
- Binary/Source Compatibility of libraries
A library is said to be binary compatible if the program that dynamically links to an earlier version of that library, continues to work using another versions of the same library. If a recompilation of the program is needed for it to run with each new version the library is said to be source compatible.
Producing binary compatible libraries is beneficial for distribution but harder to maintain by the programmer. It is often seen as a better solution to do static linking, if the library is only source compatible, since it will not cause problems to the end-user.
Binary compatibility saves a lot of trouble and is a signal that the library reached a status of stability. It makes it easier to distribute software for a certain platform. Without ensuring binary compatibility between releases, people will be forced to offer statically linked binaries.
- header-only libraries
Another distinction that is commonly made about libraries are on how they are distributed (regarding structure and use). A library that is contained only on header files is considered header-only library. Often this means that they are simpler and easy to use, however this will not be the ideal solution for complex code, it will not only hamper readability but result in larger compile times. Also depending on the compiler and it's optimizing capabilities (or options) can, due to the resulting inlining, generate larger binaries. This may not be as important in libraries mostly implemented with templates. Header-only libraries will always contain the source code to the implementation, commercial is rare.
Example: Configuring MS Visual C++ to use external librariesEdit
The Boost library is used as example library.
Considering you already have decompressed and have the binary part of the Boost library built. There the steps which have to be performed:
Set up the include directory. This is the directory that contains the header files (.h/hpp), which describes the library interface:
Set up the library directory. This is the directory that contains the pre-compiled library files (.lib):
Enter library filenames in additional dependencies for the libraries to use:
Some libraries (such as e.g. Boost) uses auto-linking to automate the process of selecting library files for linking, based on which header-files are included. Manual selection of library filenames are not required for such libraries if your compiler supports auto-linking.
In case of dynamically loaded (.dll) libraries, one also have to place the DLL-files either in the same folder as the executable, or in the system PATH.
The libraries also have to be compiled with the same run-time library as the one used in your project. Many libraries therefore come in different editions, depending on whether they are compiled for single- or multi-threaded runtime and debug or release runtime, as well as whether they contain debug symbols or not.