|
From: | John Calcote |
Subject: | Re: Setting shared lib version not functioning |
Date: | Tue, 05 May 2009 18:18:10 -0600 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 |
Hi Ralf, On 5/5/2009 2:46 PM, Ralf Wildenhues wrote:
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.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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |