|Subject:||Re: Setting shared lib version not functioning|
|Date:||Sun, 03 May 2009 10:58:09 -0600|
|User-agent:||Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2|
On 5/3/2009 9:51 AM, Jan Engelhardt wrote:
Hmmm. Jan is correct in his analysis of your versioning strategy.On Sunday 2009-05-03 17:41, Gerald I. Evenden wrote:libproject_la_LDFLAGS = -version-info 2:0:1 which worked fine when with previous loading of a library with 2:0:0 versioning code. But now, when I go through the autoreconf, configure, compile and install I get: libproject.so.1.1.0Which is absolutely correct. Either you wanted 2:1:0, or 3:0:1 (just a guess though, I can't read minds). Have a look at `info libtool`, section Versioning::.
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.
Adding the libtool list.
|[Prev in Thread]||Current Thread||[Next in Thread]|