Re: libtool versioning

Den 2010-05-06 19:45 skrev Jason Curl: On 04/05/2010 20:41, Peter Rosin wrote: Den 2010-05-04 20:00 skrev Ralf Wildenhues: Ah, ok. Yes, you're right. Feel free to commit a patch to s/removed/& or changed/ in 6. Sorry I came in late for the discussion. Is it correct to interpret "removed" as an

Re: libtool versioning

On 04/05/2010 20:41, Peter Rosin wrote: Den 2010-05-04 20:00 skrev Ralf Wildenhues: Errrm, is that really so? I tend to agree with Jef here... I take it that your response is to my "... it will work" sentence, not the paragraph below that. Ah, indeed. The algorithm *could* be interpreted su

Re: libtool versioning

irly portable abstraction of different versioning schemes implemented in different operating systems/libc's. By definition, libtool cannot do better than what the native system provides. In cases where the native system provides even less than what the libtool versioning is able to express, such a

Re: libtool versioning

Den 2010-05-04 20:00 skrev Ralf Wildenhues: Errrm, is that really so? I tend to agree with Jef here... I take it that your response is to my "... it will work" sentence, not the paragraph below that. Ah, indeed. The algorithm *could* be interpreted such that e.g. the interface change "int f

Re: libtool versioning

* Peter Rosin wrote on Tue, May 04, 2010 at 10:05:37AM CEST: > Den 2010-05-03 22:03 skrev Ralf Wildenhues: [...] > ># 3. If the library source code has changed at all since the last > >update, > ># then increment revision (`c:r:a' becomes `c:r+1:a'). > ># 4. If any interfaces

Re: libtool versioning

Den 2010-05-03 22:03 skrev Ralf Wildenhues: * Jef Driesen wrote on Mon, May 03, 2010 at 08:24:09PM CEST: Yes, I have read the libtool manual, but it doesn't contain much info about the resulting filename. Most of the info is about the c:r:a scheme for input, not the output. Yes, because the ou

Re: libtool versioning

>>> I am not a native English speaker, but I find the use of "may use" a bit confusing in the added text. I would suggest changing some instances of "may use" to "are able to use" and some to "might

Re: libtool versioning

Jef Driesen - Mon, 03 May 2010 20:24:09 +0200 >On 03/05/10 20:00, Ralf Wildenhues wrote: >> Hello Jef, >> >> * Jef Driesen wrote on Mon, May 03, 2010 at 09:08:14AM CEST: >>> On 02/05/10 03:33, Bob Friesenhahn wrote: On Sun, 2 May 2010, Jef Driesen wrote: >> The git master version of Libtoo

Re: libtool versioning

* Jef Driesen wrote on Mon, May 03, 2010 at 08:24:09PM CEST: > Yes, I have read the libtool manual, but it doesn't contain much > info about the resulting filename. Most of the info is about the > c:r:a scheme for input, not the output. Yes, because the output file name is a per-system detail that

Re: libtool versioning

On 03/05/10 20:00, Ralf Wildenhues wrote: Hello Jef, * Jef Driesen wrote on Mon, May 03, 2010 at 09:08:14AM CEST: On 02/05/10 03:33, Bob Friesenhahn wrote: On Sun, 2 May 2010, Jef Driesen wrote: I'm trying to understand the libtool current:revision:age versioning scheme. I think I understand

Re: libtool versioning

ted in different operating systems/libc's. By definition, libtool cannot do better than what the native system provides. In cases where the native system provides even less than what the libtool versioning is able to express, such as w32, it has to resort to library renaming to get even a chance o

Re: libtool versioning

Hello Jef, * Jef Driesen wrote on Mon, May 03, 2010 at 09:08:14AM CEST: > On 02/05/10 03:33, Bob Friesenhahn wrote: > >On Sun, 2 May 2010, Jef Driesen wrote: > > > >>I'm trying to understand the libtool current:revision:age versioning scheme. > >>I think I understand how it works, but I noticed th

Re: libtool versioning

On 3 May 2010, at 23:09, Bob Friesenhahn wrote: > On Mon, 3 May 2010, Matěj Týč wrote: >>> >> >> If I have understood correctly, the whole LTversion stuff has only one >> purpose - to inform users what have they installed. > > More specifically, it provides libtool with the information need

Re: libtool versioning

On Mon, 3 May 2010, Matěj Týč wrote: If I have understood correctly, the whole LTversion stuff has only one purpose - to inform users what have they installed. More specifically, it provides libtool with the information needed to produce a suitably numbered library to satisfy a purpose

Re: libtool versioning

On Mon, 3 May 2010, Jef Driesen wrote: # 6. If any interfaces have been removed since the last public release, # then set age to 0. Shouldn't step #6 included "changed" as well as "removed"? If you change the interface (for example modifying function parameters), backwards compatibility

Re: libtool versioning

>> I'm trying to understand the libtool current:revision:age versioning >> scheme. I think I understand how it works, but I noticed that filename of >> the shared library seems to get different numbers >> (current-age.age.revision). Is that expected? > > The filename generation is dependent on the

Re: libtool versioning

On 02/05/10 03:33, Bob Friesenhahn wrote: On Sun, 2 May 2010, Jef Driesen wrote: I'm trying to understand the libtool current:revision:age versioning scheme. I think I understand how it works, but I noticed that filename of the shared library seems to get different numbers (current-age.age.revi

Re: libtool versioning

On Sun, 2 May 2010, Jef Driesen wrote: I'm trying to understand the libtool current:revision:age versioning scheme. I think I understand how it works, but I noticed that filename of the shared library seems to get different numbers (current-age.age.revision). Is that expected? The filename g

libtool versioning

Hi, I'm trying to understand the libtool current:revision:age versioning scheme. I think I understand how it works, but I noticed that filename of the shared library seems to get different numbers (current-age.age.revision). Is that expected? One of the reasons why I would like to know the f

Re: libtool versioning and ABI

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 syste

Re: libtool versioning and ABI

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 ve

Re: libtool versioning and ABI

* 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 > >>v

Re: libtool versioning and ABI

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 :

Re: libtool versioning and ABI

* 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, f

Re: libtool versioning and ABI

because interfaces #7 and #6 were backwards-compatible with #5, so we skip them. "minor" and "patch" don't *explicitly* tell you any of these things. and "major" only tells you about ABI compatibility if the project managers are very careful. > I've loo

Re: libtool versioning and ABI

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-inf

Re: libtool versioning and ABI

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

Re: libtool versioning and ABI

t; ABI=51, pkgver=0.4.9 >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. I've looked into many OSS and found in Makefile.am only 2 cases : -

Re: libtool versioning and ABI

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

Re: libtool versioning and ABI

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

Re: libtool versioning and ABI

Charles Wilson - 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 >

Re: libtool versioning and ABI

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 ONL

Re: libtool versioning and ABI

* 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 la

Re: libtool versioning and ABI

ever need to use >subtraction. libtool does that for you. > >> The difficult, and somehow messy, scheme of libtool versioning is >> boring and uneasy : developers do not understand this different way >> that overlap with the classical, natural and contractual scheme (X.Y.Z &g

Re: libtool versioning and ABI

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 >

Re: libtool versioning and ABI

ent. So > why bother with complex versionning and error-prone version > manipulations with substraction *You* the developer that uses libtool shouldn't ever need to use subtraction. libtool does that for you. > The difficult, and somehow messy, scheme of libtool versioning is

Re: libtool versioning and ABI

agreement. So why bother with complex versionning and error-prone version manipulations with substraction This is supposed to make things easier. The difficult, and somehow messy, scheme of libtool versioning is boring and uneasy : developers do not understand this different way that overla

Re: libtool versioning and ABI

rface as a contract. A contract between a library writer and library user. Why does libtool want to interfere with this ... has always made me scratching my head Since it's a contract, ABI changes fall into the contract agreement. So why bother with complex versionning and error-prone version m

Re: libtool versioning and ABI

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 current-b

Re: libtool versioning and ABI

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.

Re: libtool versioning and ABI

On Wed, Aug 5, 2009 at 4:46 PM, Bruce Korb wrote: > On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvin > 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 w

Re: libtool versioning and ABI

On Wed, Aug 5, 2009 at 2:32 PM, Joseph Garvin 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 attention to ABI. It

libtool versioning and ABI

ace change since it would 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 lib

Re: Libtool versioning for the Git repository

All right, I'll try doing that. Thank you. - Original Message From: Eric Blake <[EMAIL PROTECTED]> To: libtool@gnu.org Sent: Wednesday, October 8, 2008 3:32:27 PM Subject: Re: Libtool versioning for the Git repository Jeremiah Wilson yahoo.com> writes: [your formattin

Fw: Libtool versioning for the Git repository

- Forwarded Message From: Jeremiah Wilson <[EMAIL PROTECTED]> To: Ralf Wildenhues <[EMAIL PROTECTED]> Sent: Wednesday, October 8, 2008 5:19:50 PM Subject: Re: Libtool versioning for the Git repository Sure! This is the output from my most recent gnash checkout, r

Re: Libtool versioning for the Git repository

Jeremiah Wilson yahoo.com> writes: [your formatting is messed up in this reply, because you didn't send plain text] > > > I think that instead of having the more recent version at the end of the version string, it should be in front of the parentheses.So, instead of: > libtool (GNU libtool 1.

Re: Libtool versioning for the Git repository

Hi Jeremiah, thanks for the report. I was not aware of this. * Jeremiah Wilson wrote on Wed, Oct 08, 2008 at 08:49:47PM CEST: > I think that instead of having the more recent version at the end of > the version string, it should be in front of the parentheses. > > So, instead of: libtool (GNU l

Libtool versioning for the Git repository

I think that instead of having the more recent version at the end of the version string, it should be in front of the parentheses. So, instead of: libtool (GNU libtool 1.3016 2008-10-05) 2.2.7a I propose: libtool 2.2.7a (GNU libtool 1.3016 2008-10-05) The reason for this is that certain program

Re: libtool versioning and sonames

* Andreas Metzler wrote on Sun, Oct 28, 2007 at 01:28:54PM CET: > > Are there libtool-supported archs whose versioning will break if we do > this > num c r a > 2.1.1 22 1 9 > 2.1.2 14 0 0 > > instead of > num c r a > 2.1.1 22 1 9 > 2.1.

Re: libtool versioning and sonames

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Andreas Metzler wrote on Sun, Oct 28, 2007 at 09:34:25AM CET: >> [...] However, the way libtool >> tries to represent this information in sonames (on Linux) is rather >> strange, it goes straight from libgnutls.so.13 to libgnutls.so.23. Is >> this huge

Re: libtool versioning and sonames

Hello Andreas, * Andreas Metzler wrote on Sun, Oct 28, 2007 at 09:34:25AM CET: > > [...] However, the way libtool > tries to represent this information in sonames (on Linux) is rather > strange, it goes straight from libgnutls.so.13 to libgnutls.so.23. Is > this huge jump just bug or is there a r

libtool versioning and sonames

Hello, gnutls recently had an incompatible API change (interfaces removed) and therefore made this change: num c r a 2.1.1 22 1 9 2.1.2 23 0 0 which is supposed to mean (according to the libtool manual), that 2.1.1 supported interfaces 13-22 and 2.1.2 s