[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with libtool implementation of osf style versioning

From: Rainer Orth
Subject: Re: Problems with libtool implementation of osf style versioning
Date: Mon, 10 Jun 2002 21:45:58 +0200 (MEST)

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            2.1.1:1.0:2.0

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

The proposed new scheme will create the following 1.2.2:

2:2:1     1.1.2:2.0:1.0

The old binary will look for a 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 to a 2.0
subdirectory first so the native Tru64 UNIX scheme will find the old  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$current.$age.$revision to$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            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$current.$age.$revision (i.e. in the example
above), but still use$major as the SONAME since the latest supports all upwards compatible interfaces.

This leads to the following:

2:2: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$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, while the new scheme uses$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

> > 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]