On Tue, 11 Aug 2009, Michel Briand wrote:
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:
Hello Joseph,
* Joseph Garvin wrote on Wed, Aug 05, 2009 at 11:32:31PM CEST:
I read a description of libtool's versioning here:
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
What's confusing to me is that this way of handling versioning doesn't seem
to
Ralf Wildenhues ralf.wildenh...@gmx.de - Tue, 11 Aug 2009 19:34:09
+0200
Hello Michel,
* Michel Briand wrote on Thu, Aug 06, 2009 at 12:46:00AM CEST:
Personally I've always seen interface as a contract.
A contract between a library writer and library user.
Yes.
Why does libtool want to
* Michel Briand wrote on Tue, Aug 11, 2009 at 07:53:50PM CEST:
Yes non-Linux system will have a different scheme. But if libtool wants
to help I'm sure a little more documentation could easier the task :).
# create shared lib
mylib_la_LDFLAGS = -version-info $(MYLIB_LTVERSION)
This last
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
Charles Wilson libt...@cwilson.fastmail.fm - 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
Michel Briand wrote:
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...
Yes. Here are a few
The whole story is that I never wanted to use libtool in the first
place.
And, now, I know why :).
___
http://lists.gnu.org/mailman/listinfo/libtool
Sorry for my last post : too quick answer :))
Charles Wilson cyg...@cwilson.fastmail.fm - Tue, 11 Aug 2009 16:45:58
-0400
Michel Briand wrote:
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
On Wed, 12 Aug 2009, Michel Briand wrote:
I've looked into many OSS and found in Makefile.am only 2 cases :
- version-info 1:0:0 (the guys there didn't want to bother with
libtool versioning apparently... ;))
- version-info with the X.Y.Z version back crafted to make
the soname version
On Wed, 12 Aug 2009, Michel Briand wrote:
Please give me the way to learn those ABI number you cite.
I've looked into many OSS and found in Makefile.am only 2 cases :
- version-info 1:0:0 (the guys there didn't want to bother with
libtool versioning apparently... ;))
- version-info with the
Michel Briand wrote:
libavutil49-0.4.9-3.pre1.8994.2plf2008.0
ABI=49, pkgver=0.4.9
Please give me the way to learn those ABI number you cite.
libavutil49-0.4.9-stuff
^^
is usually used by the distribution (Red Hat? Debian?) to indicate that
* Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
if i'm not mistaken, you can compute le libtool versioning from the
version of the software. If the version of the software is X.Y.Z,
the libtool version can be computed with : (X+Y).Z.Y
No, it can not, for two reasons: 1) the
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
if i'm not mistaken, you can compute le libtool versioning from the
version of the software. If the version of the software is X.Y.Z,
the libtool version can be computed with :
* Vincent Torri wrote on Wed, Aug 12, 2009 at 07:15:16AM CEST:
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
if i'm not mistaken, you can compute le libtool versioning from the
version of the software. If the version of the
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 07:15:16AM CEST:
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
if i'm not mistaken, you can compute le libtool versioning from the
version
be in C (where you only have structs so all members
are public)? Though if that were the case it seems like you'd have to
pessimistically assume ABI is always broken which doesn't sound right
either..
How does libtool versioning handle ABI breakage
On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvinjoseph.h.gar...@gmail.com wrote:
I read a description of libtool's versioning here:
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
What's confusing to me is that this way of handling versioning doesn't seem
to pay
On Wed, Aug 5, 2009 at 4:46 PM, Bruce Korb bk...@gnu.org wrote:
On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvinjoseph.h.gar...@gmail.com
wrote:
I read a description of libtool's versioning here:
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
What's
On Wed, 5 Aug 2009, Bruce Korb wrote:
Those surely sound like rule 4 to me:
If any interfaces have been added, removed, or changed since
the last update, increment current, and set revision to 0.
changing structures or funtional interfaces (inline functions),
surely is an interface change.
On Wed, 5 Aug 2009, Joseph Garvin wrote:
... But that still doesn't make sense. If I only add (don't remove functions
or change existing signatures) to my interfaces, I still bump the current
number according to that rule. But adding to an interface doesn't
necessarily break ABI. So if
Joseph Garvin joseph.h.gar...@gmail.com - Wed, 5 Aug 2009 17:02:18
-0500
On Wed, Aug 5, 2009 at 4:46 PM, Bruce Korb bk...@gnu.org wrote:
On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvinjoseph.h.gar...@gmail.com
wrote:
I read a description of libtool's versioning here:
On Thu, 6 Aug 2009, Michel Briand wrote:
Personally I've always seen interface as a contract.
A contract between a library writer and library user.
The API is the compile-time contract and the ABI is the run-time
contract.
Since it's a contract, ABI changes fall into the contract agreement.
23 matches
Mail list logo
