[Top][All Lists]

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

Re: Setting shared lib version not functioning

From: Ralf Wildenhues
Subject: Re: Setting shared lib version not functioning
Date: Tue, 5 May 2009 22:46:40 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


I think most issues were already cleared up in this thread.

* John Calcote wrote on Sun, May 03, 2009 at 06:58:09PM CEST:
>     current : revision : age
> You really have no reason to increment only the age value of a library  
> version. What you're implying by this new version of 2.0.1 is that this  
> particular instance of your library is identical in every way to the  
> previous version of 2.0.0, except that this one is now backward  
> compatible with a prior version (1.x.y).
> If you made changes to the library, but did not in any way modify the  
> interface, then you probably want to use version 2.1.0. If you modified  
> the interface in a manner that's 100% backward compatible with the  
> previous version, then you probably want 3.0.1. If you modified the  
> interface in a manner that is NOT backward compatible (i.e., you removed  
> an API function), then you probably want 3.0.0.
> It appears that Libtool is smart enough to detect ridiculous cases, but  
> it should probably throw an error of some sort, rather than simply  
> generate code with a different version number.

I agree with Jan that it is not safely possible for libtool to detect
such errors.  It detects bogus triplets such as 3:0:5, but even if it
were to look at the prior uninstalled or installed version of the
library it is about to (re)create, there is nothing that reveals whether
the triplet in the prior version was wrong, rather than the one to be
used.  So, while we could output a warning such as
  libtool: warning: library version `...' not compatible with previous `...'

I'm not sure how much good it would do.


reply via email to

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