Why dynamic linking

Originally, shared libraries and dynamic linking was sold as the way to make (newly) bloated libraries tolerable: you'd only have one copy of the library on disk and in memory, no matter how many Motif applications you had running. (Motif in specific and GUI libraries were really the original poster boys for shared libraries.)

As R. Francis Smith notes in his comment on my previous entry, these reasons are not entirely relevant any more. Disk space is cheap, and (although I haven't measured) memory usage by libraries is not likely to be the big memory consumer for modern applications.

One big reason shared libraries and dynamic linking persists is simply that it's there. Having gone through all the effort to implement it, no one is going to stop using it. (There's a general lesson here.)

But there are three big things that shared libraries are good for these days:

1. they are the underpinnings of dlopen(), which has significant uses in its own right.
2. one step fixes for bugs and security problems in library routines.
3. picking optimized CPU and system dependent routines at runtime.

The latter two are examples of runtime substitution, in these cases of non-buggy functions and of optimized functions respectively. Runtime substitution has also been used as a debugging aid, for example to transparently add a tracking malloc() to programs that are suspected of having memory leaks, and there are probably applications using it to pull off other tricks.