Re: Setting shared lib version not functioning
Hello, 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. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Setting shared lib version not functioning
Hi Ralf, On 5/5/2009 2:46 PM, Ralf Wildenhues wrote: Hello, I think most issues were already cleared up in this thread. * John Calcote wrote on Sun, May 03, 2009 at 06:58:09PM CEST: 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. When I said "ridiculous cases" I really meant "bogus triplets". I didn't think there was much you could do about valid triplets that are simply incorrect. I should think that Libtool might fail a build if a bogus triplet is passed, however. One thing that bothers me a little is that we never really did solve Gerald's original problem. He said his library was created just fine when he was passing 2:0:0, but when he switched to 2:0:1, it created a library with a version number of 1:1:0. Now, why would Libtool do this? Granted, he didn't really want 2:0:1, but 2:0:1 isn't a bogus triplet, either. So why did Libtool convert it to 1:1:0? John ___ http://lists.gnu.org/mailman/listinfo/libtool
