Roman Shaposhnik's

It is simple enough, really – both were ideas that sounded nice in theory but came crushing down during their first serious brush with reality. And since there's no shortage of experts trying to explain how come communism wasn't meant to be – I'm going to focus on the other one. But before I do, I want to make it extra clear that this article is about dynamic linking and not dynamic loading. The later one consists of dlopen(3)/dlsym(3)/dlclose(3) and is a fine idea. Dynamic linking on the other hand is all about magic that makes your application work, even though bits and pieces of it might be in places you've never heard of. And, of course, as any magic it does promise a lot. Among the biggest claims of the dynamic linking (as it is currently implemented in UNIX and similar OSes) are the following three:

1. all applications are capable of sharing common code at runtime, thus reducing total memory footprint of an entire system
2. all applications can reference common code without actually storing it as part of their ELF (or similar) file image, thus reducing total storage footprint of an entire system
3. you can fix problems in common code, thus benefiting all of the applications available on your systems at once

May be there are others, but these three are most commonly cited in favor of justifying the mind boggling complexity of the modern dynamic linkers (and if you don't believe me how complex they are – try asking our resident Solaris linker guru) and even bigger complexity of how, what I referred to as, "common code" is supposed to be packaged and delivered in order for the magic to work. Of course, given the price we pay in complexity I would expect dividends to be quite significant. Unfortunately, they are not.
The rest of this article discusses why dynamic linking does not deliver on any of its promises and why, just as communism, it might be an idea that only works in an ideal world (as a curious footnote I must add that just as communism done right seems to be doing quite well in one particular eastern country, dynamic linking within a binary compatibility guarantee of one particular OS gets as closed to being true to its promises as one can get).
The goal of this article is not to present an alternative model (I still don't have a 100% satisfactory one even for dynamic linking; not to mention communism) but to merely make the reader question whether static linking is, in fact, long dead and buried or may be the people who try very hard to make us think that way have just spent too much time in an ivory tower and haven't seen the real world in a while.
With that, let me start with tackling the last purported benefit of dynamic linking (an ability to fix problems in common code) not only because it is the easiest to knock down, but also, because once knocked it virtually eliminates the first two benefits completely. An ability to fix problems in common code and effectively addressing it once instead of doing it as many times as you have applications sharing that common code sounds really nice till you ask yourself -- what is a "problem"? What is a bug? And could it be that one application's problem is something that a second application depends upon in order to work properly? The answer to the last question is a resounding YES and there's no better example than a very prominent C++ compiler vendor who had to leave a pretty nasty C++ ABI bug unfixed for a number of years just because any possible fix would break all previously compiled applications. And of course, since C++ runtime library is dynamically linked into any application written in C++ that was unacceptable. You see, in real world programs have bugs. Worse yet -- the line between a bug and a feature sometimes gets quite blurry. That is especially true for common code. Why? For two obvious reasons: first of all, since most likely than not you didn't write the code shared by different applications yourself you have no way of knowing whether your usage patters of that common code do indeed trigger a bug, or whether they are just an example of GIGO principle. Second and most importantly -- you are very likely not to have any control over the common code and even if you can prove that the problem is indeed a bug you'd rather workaround it than wait for a vendor to issue a patch. These two issues combined create a very unpleasant situation where problems in common code now become unfixable not because we can't fix them for good, but because the old buggy behavior is now something that quite a few applications depend upon. This is a classical "doomed if you do, doomed if you don't" principle at work. But where does it leave us as far as dynamic linking goes? In a mess! And a big one at that. All of a sudden we have a system where half of the applications want that piece of common code fixed and the other half wants it broken. All of a sudden we have to make sure that we CAN isolate applications that still depend on an old buggy behavior and the magic of dynamic linking just starts getting blacker and blacker with abominations like LD_LIBRARY_PATH and DSO symbol versioning. What we've got on our hands now is a simple situation where common code becomes segmented in a sense that it is common among just a subset of applications. And that is the point where dynamic linking just breaks. There's no way for my application to be sure that the same common code I tested it with is the one that is being in use. And for any serious software vendor that is just unacceptable. You see, serious software vendors care about their customers and they don't play finger pointing games saying things like: it is all your fault you should have not upgraded that shared library over there. What do they do instead? Well, just try to do

find . -name \.so

to see for yourself. If you do that with any commercial piece of software (or even free large ones like Open Office) don't be surprised to see things like private versions of glibc.so being repackaged and redelivered. It is much safer for them to do that instead of constantly dreading the ugly upgrade of /lib/libc.so.
But wait! Haven't it just annulled the first and the second claims that the dynamic linking had? Sure it did. There's no sharing possible between /lib/libc.so and /opt/bigapp/lib/glibc.so. None. The memory gets wasted as much as the diskspace does. It might as well be static linking at that point.
In fact, static linking would be quite beneficial for the application since if done right with the smart compiler it would enable things like: not wasting precious CPU cycles on position independent code (if you think PIC is free see Performance Analyzer in action), doing interprocedural optimization, cross-file inlining and template elimination. And a few others. And unlike dynamic linking you can be dead certain that the very same code you tested would be working at your customer's site. Not only that -- but when you do need to fix it, you fix wouldn't break anybody else.
Ain't this the magic?