Re: libtool versioning and ABI

[Vincent Torri]

On Wed, 12 Aug 2009, Ralf Wildenhues wrote:

> * Vincent Torri wrote on Wed, Aug 12, 2009 at 07:15:16AM CEST:
> > On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
> > > * Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
> > > > if i'm not mistaken, you can compute le libtool versioning from the
> > > > version of the software. If the version of the software is X.Y.Z,
> > > > the libtool version can be computed with : (X+Y).Z.Y
> > >
> > > No, it can not, for two reasons: 1) the version of the software and the
> > > shared library version are completely unrelated; 2) you are thinking in
> > > terms of GNU/Linux shared library versioning only, not seeing that there
> > > are other systems.
> > >
> > > This thread is all about why your statement is wrong.  Please read it.
> >
> > i've read it. But the way we change X, Y and Z follows exactly the
> > libtool versioning 
> > (http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info)
> > with the formula above.
>
> What does that have to do with it?  That statement is completely
> unrelated to what you said before.
>
> Example showing why your first statement above is wrong:
>
> I have a package called foo, at version 2.13.

we use a micro version number, not only a major and minor version 
numbers; so all you say below is unrelated to what i described above:

AC_INIT([eet], [1.2.2], address@hidden)
AC_PROG_LIBTOOL
VMAJ=`echo $PACKAGE_VERSION | awk -F. '{printf("%s", $1);}'`
VMIN=`echo $PACKAGE_VERSION | awk -F. '{printf("%s", $2);}'`
VMIC=`echo $PACKAGE_VERSION | awk -F. '{printf("%s", $3);}'`
SNAP=`echo $PACKAGE_VERSION | awk -F. '{printf("%s", $4);}'`
version_info=`expr $VMAJ + $VMIN`":$VMIC:$VMIN"


Vincent Torri

> It consists of a lot of
> junk, plus two shared libraries created with libtool, libfoo and
> libbar.  libfoo is currently at the Libtool version triple 3:27:0,
> libbar is currently at the Libtool version triple 17:105:1.
>
> With our foo next release, 2.14, libfoo will probably have 3:28:0,
> libbar will probably have 18:3:2.
>
> All of this is very much conforming to the link you posted.  But it has
> *nothing* to do with the version of the package (2.13 resp 2.14 here).
> And I have not said a word about the soname of the libraries on
> GNU/Linux (which is what you are trying to get the computation from).
>
> The fact that, on GNU/Linux, the version triple 17:105:1 might cause a
> library with soname libfoo.so.16 to be created, is a detail that I don't
> care about.  I am aware of it, and distros might have to deal with it,
> but I am just as aware that on other systems, the *same* triple might
> cause a library with soname libfoo.so.17.1 to be created, or with DLL
> name libfoo-16.dll or what not else.
>
> --
> Ce message a été vérifié par MailScanner
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
> Message délivré par le serveur de messagerie de l'Université d'Evry.