Q. What are three benefits of dynamic (shared) linkage of libraries compared to static linkage? What are two situations where static linkage is preferable?
Answer: The primary benefits of shared libraries are that they decrease the memory and disk space used by a system and they enhance maintainability.
When shared libraries are being utilized by all running programs there is only one instance of every system library routine on disk and at most one instance in physical memory. When the library in question is one utilized by many applications and programs then the disk as well as memory savings can be quite substantial. Additionally the start-up time for running new programs can be summary since numerous of the common functions needed by that program are likely to be previously loaded into physical memory.
Maintainability is as well a most important advantage of dynamic linkage over static. If all running programs utilize a shared library to access their system library routines then upgrading those routines whichever to add new functionality or to fix bugs can be complete simply by replacing that shared library. There is no requirement to recompile or re-link any applications several programs loaded subsequent to the upgrade is complete will automatically pick up the new versions of the libraries.
There are other benefits too. A program that uses shared libraries can frequently be adapted for specific purposes merely by replacing one or more of its libraries or even (if the system allows it and most UNIXs including Linux do) adding a new one at run time. For instance a debugging library can be substituted for a normal one to trace a problem in an application. Shared libraries as well allow program binaries to be linked against commercial proprietary library code without essentially including any of that code in the program's final executable file. This is significant because on most UNIX systems several of the standards shared libraries are proprietary as well as licensing issues may prevent including that code in executable files to be distributed to third parties.
In some places nevertheless static linkage is appropriate. One example is in rescue environments for system administrators. If a system administrator makes a fault while installing any new libraries or if hardware develops problems it is quite probable for the existing shared libraries to become corrupt. Consequently frequently a basic set of rescue utilities are linked statically therefore that there is an opportunity to correct the fault without having to rely on the shared libraries functioning correctly.
There are as well performance advantages that sometimes make static linkage preferable in special cases. For a start dynamic linkage does raise the start up time for a program as the linking should now be done at run time rather than at compile time. Dynamic linkage can as well sometimes raise the maximum working set size of a program (the total number of physical pages of memory necessary to run the program).
In the shared library the user has no control over where in the library binary file the variety of functions reside. Since most functions don't precisely fill a full page or pages of the library loading a function will frequently result in loading in parts of the surrounding functions too. With static linkage absolutely no functions that aren't referenced (directly or indirectly) by the application require to be loaded into memory.
Other issues surrounding static linkage comprise ease of distribution: it is simpler to distribute an executable file with static linkage than with dynamic linkage if the distributor isn't certain whether the recipient will have the correct libraries installed in advance. There may as well be commercial restrictions alongside redistributing some binaries as shared libraries. For instance the license for the UNIX Motif graphical environment allows binaries using Motif to be distributed freely as long as they are statically linked however the shared libraries may not be utilized without a license.