> A. The major advantage of a shared library is that it may contain code that
> more than one binary depends on. Thus, this code is only stored once,
> in the shared library, and not in each individual binary. This saves
> storage space on disk, especially when dealing with very common code
> that nearly every program needs. But the benefits go farther than the
> space savings: if the common code needs to be updated (for example, a
> patch to fix a bug), this need only be done once, in the shared library.
> (There are also more reasons, covered below).
As opposed to, say, a _separate program_?
One of the many advantages of a separate program is that it may contain
code that more than one binary depends on. Thus, the code is only stored
once, in the separate program, and not in each individual binary. This
saves storage space on disk, especially when dealing with very common
code that nearly every program needs. But the benefits go farther than
the space savings: if the common code needs to be updated (for example,
a patch to fix a bug), this need only be done once, in the separate
Another massive advantage is that separate programs are supported by
every UNIX system.
Quote:> A. It takes time for a program to load all of the shared library files it
> needs and to link them to the main program and to other shared libraries
> (called dynamic linking). The program will take longer to start up.
In contrast, modular programs are usually much faster than integrated
programs. They load from disk much more quickly, and they don't have to
do anything special before jumping into main(). Any commonly used
separate program (such as a compression program) is probably in memory
at any moment---the VM system worries about this---so it'll be there the
instant you execute it.
(Of course, some programs do so little useful computation, and so much
data movement, that modularity becomes an efficiency problem. For these
rare programs it helps if the OS allows fast message passing---i.e.,
program 1 asks the OS for a VM buffer, program 1 writes data into the
buffer, program 1 hands the buffer to program 2 without copying it.)
Quote:> Finally, the system must be able to locate the require libraries
> wherever they may be, which is, again, error prone. (See "What
> is LD_LIBRARY_PATH?")
Of course, the system also has to be able to locate separate programs,
but PATH is much more familiar to users than LD_LIBRARY_PATH.
[ Solaris now supports on-the-fly loading of shared libraries: ]
Quote:> To summarize, it is possible to select one or another
> version of a set of alternative functions by loading one or
> another shared library containing the same function, depending
> on values found in a configuration file, or even depending on
> user input.
Separate programs handle this trivially (and portably).
Quote:> Q. So should I use shared libraries?
> A. The real answer is of course, "it depends". But the easy answer is yes.
> It seems to be the opinion of the community in general that the
> advantages outweigh the disadvantages.
Of course. Shared libraries work wonders with hulking monoliths of code.
Most programs today are hulking monoliths of code. A kluge whose value
rests on the popularity of poor programming practice is a valuable kluge