[Top][All Lists]
[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 ?
- libtool versioning and ABI, Joseph Garvin, 2009/08/05
- Re: libtool versioning and ABI, Bruce Korb, 2009/08/05
- Re: libtool versioning and ABI, Joseph Garvin, 2009/08/05
- Re: libtool versioning and ABI, Bob Friesenhahn, 2009/08/05
- Re: libtool versioning and ABI, Michel Briand, 2009/08/05
- Re: libtool versioning and ABI, Bob Friesenhahn, 2009/08/05
- Re: libtool versioning and ABI, Ralf Wildenhues, 2009/08/11
- Re: libtool versioning and ABI, Michel Briand, 2009/08/11
- Re: libtool versioning and ABI, Ralf Wildenhues, 2009/08/11
- Re: libtool versioning and ABI, Charles Wilson, 2009/08/11
- Re: libtool versioning and ABI,
Michel Briand <=
- Re: libtool versioning and ABI, Charles Wilson, 2009/08/11
- Re: libtool versioning and ABI, Michel Briand, 2009/08/11
- Re: libtool versioning and ABI, Michel Briand, 2009/08/11
- Re: libtool versioning and ABI, Vincent Torri, 2009/08/11
- Re: libtool versioning and ABI, Ralf Wildenhues, 2009/08/12
- Re: libtool versioning and ABI, Vincent Torri, 2009/08/12
- Re: libtool versioning and ABI, Ralf Wildenhues, 2009/08/12
- Re: libtool versioning and ABI, Vincent Torri, 2009/08/12
- Re: libtool versioning and ABI, Daniel Herring, 2009/08/11
- Re: libtool versioning and ABI, Charles Wilson, 2009/08/11