Re: libtool versioning and ABI

[Charles Wilson]

Michel Briand wrote:
> This last variable is crafted

"crafted"? This is your mistake.

> to reflect the usual versioning. I.e. if
> I want the version to 1.22.5,

Why? Why do you CARE what the internal ABI version number is?  It's just
a tag; you shouldn't care WHAT it is, only that it changes ONLY when it
actual has to, to reflect binary (in)compatibility.  libfoo.so.27.1.2 is
part of foo-3.1.2.  Big deal.  There's no need that it MUST be
libfoo.so.3.1.2 with SONAME "libfoo.so.3"

> I must put 23:5:22 in the _LTVERSION
> variable (effectively doing substractions ;^^).

No, you must change your GNU/Linux/ELF-centric thinking about shared
libraries.

======================================================================
7.4 Managing release information
================================

Often, people want to encode the name of the package release into the
shared library so that it is obvious to the user which package their
programs are linked against.  This convention is used especially on
GNU/Linux:

     trick$ ls /usr/lib/libbfd*
     /usr/lib/libbfd.a           /usr/lib/libbfd.so.2.7.0.2
     /usr/lib/libbfd.so
     trick$

   On `trick', `/usr/lib/libbfd.so' is a symbolic link to
`libbfd.so.2.7.0.2', which was distributed as a part of
`binutils-2.7.0.2'.

Unfortunately, this convention conflicts directly with libtool's
idea of library interface versions, because the library interface
rarely changes at the same time that the release number does, and the
library suffix is never the same across all platforms.
======================================================================

Basically, you are accustomed to a particular quirk of ELF DSOs and the
way Linux distributors have been packaging them.  But that "quirk" is
NOT a fundamental part of the idea of shared libraries -- and they do
not work that way on many, many platforms.

The SONAME should distinguish the major (ABI breaking) versions of the
library.  When FOSS projects are *careful*, many times this does, in
fact, correspond with actual major releases of the package itself.
(e.g. foo-2.x.y breaks binary compatibility with foo-1.x.y).

They are not always careful.

And, just because ABI compatibility is preserved on one specific class
of system (32bit GNU/Linux) does not mean that 1.x+1.y or even 1.x.y+1
doesn't break ABI compatibility on some other system.

ABI version != package version. Stop thinking that they are. (It is, of
course, good manners to *bump* the major package version when you
deliberately modify the ABI.  But just because "change package version
from X.Y.Z to X+1.Y.Z, whenever SONAME S changes", that doesn't mean
that X = S.  In fact, if you are using libtool, many times the SONAME
will jump by more than one:

   foo-1.7.2    -version-info 15:2:5   SONAME libfoo.so.10  S = 10
make one ABI-breaking change, and the "rules" say that version info becomes
                -version-info 16:0:0   SONAME libfoo.so.16  S = 16
It's good manners to release this new version as
   foo-2.0.0
(not foo-16.0.0)

And your typical linux distribution would package the results as

old:
libfoo-devel-1.7.2-<relver>-<pkgfmt>
libfoo10-1.7.2-<relver>-<pkgfmt>
foo-1.7.2-<relver>-<pkgfmt>

new:
libfoo-devel-2.0.0-<relver>-<pkgfmt>
libfoo16-2.0.0-<relver>-<pkgfmt>
foo-2.0.0-<relver>-<pkgfmt>

See? No relation between "1.7.2" and "10", nor between "2.0.0" and "16".

--
Chuck