Re: Problems with libtool implementation of osf style versioning

[Albert Chin]

[ address@hidden removed from Cc:]

On Mon, Jun 10, 2002 at 03:08:45PM +0200, Rainer Orth wrote:
> Trying to install both gcc 2.95 and 3.1 on Tru64 UNIX into a common prefix,
> I noticed a serious problem with the current implementation of the osf
> versioning style.
>
> [ long explanation of Tru64 library version skipped (excellent job
>   though ]
> 
> To avoid both the need for manual intervention by creating subdirectories
> of libdir and moving old versions there and the unnecessary double access
> to newer and old library version, I suggest that libtool implements the osf
> style versioning scheme like it currently does for the irix style.
> 
> The example above would look like this instead:
> 
> osf   Files                           SONAME          IVERSION
> 
> 0:0:0 lib.so lib.so.0 lib.so.0.0.0    lib.so.0        0.0.0:0.0
> 0:1:0 lib.so lib.so.0 lib.so.0.0.1    lib.so.0        0.0.1:0.0
> 1:0:1 lib.so lib.so.0 lib.so.0.1.0    lib.so.0        1.1.0:1.0:0.0
> 1:1:1 lib.so lib.so.0 lib.so.0.1.1    lib.so.0        1.1.1:1.0:0.0
> 2:0:0 lib.so lib.so.2 lib.so.2.0.0    lib.so.2        2.0.0:2.0
> 
> This is a merge of the linux (used on Solaris 2 as well) and irix
> versioning schemes, listed below for reference:
> 
> linux Files                           SONAME
> 
> 0:0:0 lib.so lib.so.0 lib.so.0.0.0    lib.so.0
> 0:1:0 lib.so lib.so.0 lib.so.0.0.1    lib.so.0
> 1:0:1 lib.so lib.so.0 lib.so.0.1.0    lib.so.0
> 1:1:1 lib.so lib.so.0 lib.so.0.1.1    lib.so.0
> 2:0:0 lib.so lib.so.2 lib.so.2.0.0    lib.so.2
> 
> irix  Files                           SONAME          IVERSION
> 
> 0:0:0 lib.so lib.so.1 lib.so.1.0      lib.so.1        sgi1.0
> 0:1:0 lib.so lib.so.1 lib.so.1.1      lib.so.1        sgi1.0:sgi1.1
> 1:0:1 lib.so lib.so.1 lib.so.1.0      lib.so.1        sgi1.0
> 1:1:1 lib.so lib.so.1 lib.so.1.1      lib.so.1        sgi1.0:sgi1.1
> 2:0:0 lib.so lib.so.3 lib.so.3.0      lib.so.3        sgi3.0

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?

> The changes in the proposed new scheme are as follows:
> 
> * Record the oldest compatible version in the SONAME and install a matching
>   symlink.  This avoids the need for manually creating subdirs and moving
>   old versions there.
> 
> * 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?

> * Record the same triplet in the IVERSION field.  As above, this is purely
>   informational, so nobody is affected by this change.
> 
> * Revert the ordering of major versions in the IVERSION field.  This will
>   cause binaries linked against a `new' library to pick up the oldest
>   version implemented, not the newest one.
> 
>   Unlike the irix scheme (which only records revision information for the
>   current version in the IVERSION field; this is problematic in itself, but
>   not the focus of the current message), the osf style recorded all
>   compatible versions implemented by the current dso, so we need to list
>   all of them so binaries linked against either old 1.0 or 0.0 versions
>   will continue to run.
> 
> 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?

-- 
albert chin (address@hidden)