|
A shared library is also known as shared object, or as a dynamically linked library. It is similar to an archive in that it is a grouping of object files. However the difference being that after linking the shared library into a program, the code present in the shared library is not contained by the final executable. Instead, only a reference to the shared library is present with the executable. With multiple programs running on the system, even if all of them would be linked with same shared library, but none will actually be included.
A second difference is that a shared library being not just a mere collection of object files, from which the linker chooses those needed for satisfying undefined references. The object files composing the shared library are instead combined into a single object file so that if a program tries to link against a shared library, it should always include all of the code in the library rather than just those portions that are needed.
To create shared library, you must compile the objects that will make up the library using the –fPIC option to the compiler, like this:
% gcc –c –fPIC sample1.c
The –fPIC option gives an idea to the compiler that sample1.o is to be used as part of a share object. Then you combine the object files into a shared object, like this:
% gcc –shared –fPIC –o libtest.so sample1.o sample2.o
The linker knows that it is to produce a shared library rather than an ordinary executable through the –shared option. Shared libraries are denoted by .so extension standing for shared object. Like static archives the name always begins with lib to indicate that the file is a library.
Linking with the shared library is just like linking with a static archive. For example the following line will link with libtest.so if it is in the current directory, or one of the standard library search directories on the system:
% gcc –o app app.o –L –ltest
Suppose that both libtest.a and libtest.so are available. Then the linker must choose one of the libraries and not the other. Each directory is being searched by the linker. But first the directories specified with –L options are searched and then those in the standard directories. The linker stops searching the directories once it finds a directory containing either libtest.a or libtest.so. In case of only one variant being present in the directory, the linker chooses that variant which is present in that directory. Otherwise the shared library version is chosen by the linker, unless the user explicitly instructs it. Users can use –static option for static archives. For example, libtest.a archive will be used in the following lines even if libtest.so is available:
% gcc –static –o app app.o –L –ltest
In order to display those shared libraries which are linked to an executable, ldd command is used. Availability of these libraries needs to be checked while running the executable.
Advantages of Shared Library
One major advantage of shared library is that it saves space on the system where the program is installed. If you are installing ten programs and they all make use of the same shared library than you save a lot of space by using a shared library. If you need a static archive instead, the archive is included in all ten programs. Using shared library also reduces the download times if your program is being downloaded from the web.
However, usage of static archives is being promoted due to several reasons. There are several disadvantages also. All programs depending on the shared library get affected with the upgrade of Shared Library. For eg. While developing mission-critical software, you might rather link to a static archive so that an upgrade to shared libraries on the system won’t affect your program.
Altogether a proper weighing of these advantages and disadvantages needs to be done for every program before distributing.
|
