Re: libtool versioning and ABI

From:

Michel Briand

Subject:

Re: libtool versioning and ABI

Date:

Tue, 11 Aug 2009 21:34:46 +0200

Charles Wilson <address@hidden> - Tue, 11 Aug 2009
14:50:33 -0400
>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.
>
Please......
[...]
>
> 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)
So ... that was a practical concern of me : how to manage those 2
parallel versioning systems ;)....
>
>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
Thank you, but, sorry, I'm not convinced. Remember what I said a
few mails ago: that's all of interface contract = same concept as
your...
Does anyone uses "10" or "16" to refer to their ABI ? Hum... So those
numbers have to be managed somewhere...
If developers and users are ok with X.Y.Z then the CURRENT, REVISION
and AGE is a different scheme to learn and to implement in the build
system: that need to be managed in parallel. That's to say that if dev
makes some changes in ABI and bumps the version up (say X.Y.Z+1),
someone has to think about the weird libtool thing and update the
libtool's versioning, making substractions and the like...
And no matter the operating system : on most the .so will have no
number at all.
Crafted: yes, crafted. Since I use X.Y.Z as a comprehensive label for
devs and users, I have to craft the C:R:A to reflect that...
So any practical method ?