A library is really nothing more than a collection of object files. When the collection of object files provides related behavior to solve a given problem, the objects can be integrated into a library to simplify their access for application developers.
Static libraries are created using the ar , or archive, utility. Once the application developer compiles and then links with the library, the needed elements of the library are integrated into the resulting executable image. From the perspective of the application, the external library is no longer relevant because it s been combined with the application image.
Shared, or dynamic, libraries are also linked with an application image, but in two separate stages. In the first stage (at the application s build time), the linker verifies that all of the symbols necessary to build the application (functions or variables ) are available within either the application or libraries. Rather than pull in the elements from the shared library into the application image (as was done with the static library), at the second stage (at runtime) a dynamic loader pulls the necessary shared libraries into memory and then dynamically links the application image with them. These steps result in a smaller image, as the shared library is separate from the application image (see Figure 6.1).
The tradeoff to this memory saving for shared libraries is that the libraries must be resolved at runtime. This requires a small amount of time to figure out which libraries are necessary, find them, and then bring them in to memory.
In the next sections, we ll build a couple of libraries using both the static and shared methods to see how they re built and how the program changes to support them.