[Top][All Lists]

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

Re: libtool versioning and ABI

From: Charles Wilson
Subject: Re: libtool versioning and ABI
Date: Tue, 11 Aug 2009 14:50:33 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090605 Thunderbird/ Mnenhy/

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. is
part of foo-3.1.2.  Big deal.  There's no need that it MUST be with SONAME ""

> 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

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

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

   On `trick', `/usr/lib/' is a symbolic link to
`', which was distributed as a part of

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  S = 10
make one ABI-breaking change, and the "rules" say that version info becomes
                -version-info 16:0:0   SONAME  S = 16
It's good manners to release this new version as
(not foo-16.0.0)

And your typical linux distribution would package the results as



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


reply via email to

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