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