On Wed, 4 Feb 2004, Todd Vierling wrote:

> On Wed, 4 Feb 2004, Luke Mewburn wrote:
>
> : The /usr/lib/libfoo.so.N.M symlinks to /lib were just for consistency
> : with the non-symlinked libraries.
> :
> : I'm ambivalent about whether they're needed or not; I'll wait
> : to see what other toolchain-clued people have to say.
>
> They're unneeded.  ELF has no idea what those libraries are.  8-)

This is as good a time as any to point out, that I'm starting to think
we're doing this all wrong in regards to so-called "minor versions"
(i.e., additions, but not changes, to the ABI). The problem is, that
there's no way to detect if a program were built to an ABI that's
newer than, and therefore extended from, the one that's available.

Bumping the "major" isn't the right thing to do, either, since that
fails to appreciate the usual situation, where an older binary could
happily run against a newer shared library.

To cut to the chase, this is what I think we should be doing:

    libfoo.so -> libfoo.so.0.3
    libfoo.so.0.0 -> libfoo.so.0.3
    libfoo.so.0.1 -> libfoo.so.0.3
    libfoo.so.0.2 -> libfoo.so.0.3
    libfoo.so.0.3

All the DT_SONAMES in the shared libraries, and therefore the NEEDED
in the binaries, should have the full filename, such as "libfoo.0.3".

Observe that a binary linked against "libfoo.0.2" will happily be
redirected to "libfoo.0.3", and run fine, as before.

But now look what happens when you try to run a binary linked against
"libfoo.so.0.4". The run-time linker will say "...not found" rather
than <insert horrible things>.

I'm pretty sure this topic came up back when we were switching so ELF,
but no one truly appreciated the problems the course chosen would
create for those rare producers of binary packages (i.e. "pkgsrc").
Am I wrong?

Frederick