Executive summary: 

No, we dont really have minor numbers in ELF.  They exist ony in
filesystem namespace and symlink craziness; they are ompletel
invisible to ld.elf_so, the .so files ,and the apps used against them.
So caveat emptor.

In message <199908170717.JAA04362@jdolecek.per4mance.cz>
Jaromir Dolecek writes:

>> 2) "DLL Hell" must be avoided; in the Windows world, conflicting or "upgrade
>"
>> DLLs sometimes render older apps inoperative, since the newer DLLs sometimes
>> aren't bug-for-bug compatible.
>
>The problem on M$ windows [...]
>is that there are occasions when the DLL
>has same name and other functionality; related problem is that
>applications on windows tend to install their own system libraries.
>If you install older app, you may well break some newer one, which
>uses newer version of the system library.
>
>It's avoided by Unix's major and minor version numbering - when
>the functionality changes, the major is raised and old app doesn't
>use this new library. If just the interface is enhanced (i.e. new
>functions are added), the minor number is raised; old binaries use
>new library and even new binaries linked against new library work
>with the old library, if they don't use the new functionality.
>If just some bugs are fixed, the version number is not changed at all,
>as the interface has not changed either (with exception with Linux,
>which has even patch level in their library names).
>
>DLL hell is not an issue on Unix, AFAIK. I'm tempted to start bashing
>MS for a lousy scheme they came up, but I won't.

That was more-or-less true for the SunOS-style (sans silly-archives)
a.out shared libraries we used to have.  it's just nottrue for ELF.
THere, you have two choices: hard bind the application to a specific
major/minor pair; or  link it against the shared-lib major number only,
and rely on symlink hairiness to find the `most recent' version.

Even that  much doesn't always work,  e.g., with pkg'ised libraries:
the pkg system may refuse to let you install a nerwer library with
a newer soure-code  `minor'  number. That can be a real pain, if you want
pkg P1, which needs library version X.Y, but X.Y conflicts with package
P2 whichneeds version X.Z (where Z != Y).


Case in point: prebuilt i386 binary packages for 1.4{,.1} for slrn and lynx
disagree over libslang -- precisely what you say doesn't happen with Unix.
(If you want both slrn and lynx, you have to build one or other from
source. Yucko.)

> it's not very common you WANT to be bug-for-bug compatible --
>normally you want to have the bugs fixed ....

Not if applications wer written oblivous to the bugs and then end up
*depending* on them. check out the vt220 termcap :).

>Anyway, the issue here is very different from M$ windows world - if there
>is bug in library you'd want to avoid, you can go and fix the
>library for you, which is not possible on M$ windows. You don't
>need to work-around that.

True, but it rather ignores people who want prebuilt software.  just
works. Even crusty old hackers from comp.bugs.4bsd fit that profile,
these days, for must stuff they arent hacking on directly.


>> I think the only general solution for this is to use the exact library with
>> a given ap.  Perhaps some kind of "SCCS" for library files could be used,
>> so that a binary diff could be applied to a current library file to make
>> available previous versions.
>
>Not needed. major.minor is just enough.

But we *dont have* major.minor any more. For all practical purposes,
with ELF, all we have is major. That's all that gets linked into the
binaries and the .so files, and its all that ld.elf_so gets to see.
Sure, you can leave lower-minor-numbered libs around and futz with

	ln -s libFOO.so.mj.{last-minor-known-to-wr> libFOO.so.maj

if things break.  And if you end up in *that* territory, a ldconfig
whichy makes the `right' symlinks is probably something you'd really
rather have than not. (we dont, for what're essentially reasons rather
than rational engineering ones.)