libtool
[Top][All Lists]
Advanced

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

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 ?





reply via email to

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