Development System - Shared Libraries
One disadvantage of static libraries is that when we run many applications at the same time and they all use functions from the same library, we may end up with many copies of the same functions in memory and indeed many copies in the program files themselves. This can consume a large amount of valuable memory and disk space.
Many UNIX systems and Linux support shared libraries can overcome this disadvantage. A complete discussion of shared libraries and their implementation on different systems is beyond the scope of this book, so we’ll restrict ourselves to the visible implementation under Linux.
Shared libraries are stored in the same places as static libraries, but shared libraries have a different filename suffix. On a typical Linux system, the shared version of the standard math library is /usr/lib/libm.so.
When a program uses a shared library, it is linked in such a way that it doesn’t contain function code itself, but references to shared code that will be made available at run time. When the resulting program is loaded into memory to be executed, the function references are resolved and calls are made to the shared library, which will be loaded into memory if needed.
In this way, the system can arrange for a single copy of a shared library to be used by many applications at once and stored just once on the disk. An additional benefit is that the shared library can be updated independently of the applications that rely on it. Symbolic links from the /usr/lib/libm.so file to the actual library revision (/usr/lib/libm.so.N where N represents a major version number—6 at the time of writing) are used. When Linux starts an application, it can take into account the version of a library required by the application to prevent major new versions of a library from breaking older applications.
For Linux systems, the program (the dynamic loader) that takes care of loading shared libraries and resolving client program function references is called ld.so and may be made available as ldlinux.so.2 or ld-lsb.so.1. The additional locations searched for shared libraries are configured in the file /etc/ld.so.conf, which needs to be processed by ldconfig if changed (for example, if X11 shared libraries are added when the X Window System is installed).
We can see which shared libraries are required by a program by running the utility ldd. For example, if we try running it on our example application, we get the following:
$ ldd program
libc.so.6 => /lib/libc.so.6 (0×4002a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)
In this case, we see that the standard C library (libc) is shared (.so). Our program requires major Version 6. Other UNIX systems will make similar arrangements for access to shared libraries. Refer to your system documentation for details.
In many ways, shared libraries are similar to dynamic-link libraries used under Windows. The .so libraries correspond to .DLL files and are required at run time, while the .sa libraries are similar to .LIB files included in the program executable.