Re: Problems with libtool implementation of osf style versioning

[Rainer Orth]

Albert Chin writes:

> Doesn't this break backwards compatibility? If I have libpng 1.2.1
> built with the old libtool and libpng 1.2.2 with the new libtool,
> won't all the programs linked against libpng 1.2.1 break when the
> libpng 1.2.2 libraries overwrite the 1.2.1 libraries?

I don't think so:

Suppose libpng 1.2.1 used -version-info 2:1:1 and 1.2.2 uses 2:2:1 (i.e. no
interface change, only an upgrade in revision).  The old libtool creates

        Files                                   SONAME          IVERSION
2:1:1   libpng.so libpng.so.2.1.1               libpng.so       2.1.1:1.0:2.0

A binary linked against this file will record libpng.so and depend on
version 2.0 (the rightmost one in the IVERSION list).

The proposed new scheme will create the following libpng.so 1.2.2:

2:2:1   libpng.so libpng.so.1 libpng.so.1.1.2   libpng.so.1     1.1.2:2.0:1.0

The old binary will look for a libpng.so implementing version 2.0, which
the current one does.

If you install (say) libpng 2.0.0 (with -version-info 3:0:0, an
incompatible upgrade), you will have to move the old libpng.so to a 2.0
subdirectory first so the native Tru64 UNIX scheme will find the old
libpng.so.  Encoding $major in the SONAME avoids this.

But the new scheme has another problem, as I just saw in this example: the
change of filename from libpng.so.$current.$age.$revision to
libpng.so.$major.$age.$revision might overwrite an older library version
(and break binaries currently having the older file open).

Consider -version-info 1:2:1 in the old scheme.  This gives

1:2:1   libpng.so libpng.so.1.1.2               libpng.so       1.1.2:0.0:1.0

(Though this seems strange: age is 1 both here and above, meaning that the
library above implements both (upwards compatible) interfaces 0 and 1, but
the first example implements only 1 and 2!?  I'd expect 2:2:2 instead.)

To avoid this, on has to leave the real filename at
libpng.so.$current.$age.$revision (i.e. libpng.so.2.1.2 in the example
above), but still use libpng.so.$major as the SONAME since the latest
libpng.so.1 supports all upwards compatible interfaces.

This leads to the following:

2:2:1   libpng.so libpng.so.1 libpng.so.2.1.2   libpng.so.1     1.1.2:2.0:1.0

Whether one encodes 1.1.2 ($major.$age.$revision) or 2.1.2
($current.$age.$revision) in the leftmost IVERSION field is up to debate:
the latter is probably less confusing.

> > * Install the libraries as lib.so.$major.$age.$revision as in the linux
> >   scheme.  Since those filenames are not used except as symlink targets,
> >   this change won't affect any binary, whether built with the old or new
> >   implementations of the osf versioning scheme.
> 
> But won't the SONAME change?

Sure: in the old scheme, it was always libpng.so, while the new scheme uses
libpng.so.$major.  But it doesn't matter: the runtime linker only uses the
SONAME to look up the shared library to use; it doesn't check if the SONAME
embedded in the library found matches the NEEDED field in the executing
binary.

> > If there's agreement that this change (primarily the encoding of the major
> > version in the SONAME) is reasonable, I'll post a patch to implement this.
> 
> Against 1.4 and HEAD?

I can probably do so: the change will be almost identical, only the
affected files change.

        Rainer