Remember back before Gnome, when Linux didn't have its own version of DLL hell (SO_PURGATORY?)?

Okay, for the uninitiated, would you mind explaining how Gnome created DLL Hell?

DLL Hell is, to me, the following situation:

Program1: Graphics viewer. Requires common graphics library vA.B.C
Program2: Graphics editor. Requires common graphics library vD.E.F

In Windows, there is the potential for DLL hell here, because there is only one version of "CommonGraphicsLibrary.dll" (more likely CMGFXLIB.DLL or something) in %SYSTEMROOT%\SYSTEM32. If that version is vD.E.F, it should theoretically be backwards compatible with vA.B.C, but if it's not, you've got a problem. Worse, if you installed Program1 after you installed Program2, and the installer doesn't behave right and "downgrades" the library, Program2 is broken. This is my understanding of DLL Hell.

In this example, Gnome or no Gnome, there is no DLL hell. /usr/lib/libpng.so.A will be used by Program1, and /usr/lib/libpng.so.D will be used by Program2.

How exactly did Gnome create DLL hell in Linux? It seems to me there's always potential for "Dependency Hell" anytime you do dynamic loading of libraries, just beacuse there's always a chance you've got a stray version of the library somewhere. Is there something GNOME is doing with regards to shared objects that I'm not familiar with?