[Top][All Lists]

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

Re: Setting shared lib version not functioning

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:

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?


reply via email to

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