[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: Wed, 6 May 2009 22:19:05 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi John,

* John Calcote wrote on Wed, May 06, 2009 at 02:18:10AM CEST:
> 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.

Which triplets are you thinking of that libtool should fail with, but
currently doesn't?

> 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?

* Andreas Schwab wrote on Wed, May 06, 2009 at 11:15:30AM CEST:
> For the linux way of library versioning the library suffix is computed
> as (current-age).age.revision, thus 2:0:1 maps to 1.1.0.  A libtool
> version of 1:1:0 whould map to 1.0.1.

Exactly.  With a triplet of 2:0:1, on GNU/Linux, a version number of
1.1.0 is one that has semantics consistent with the semantics described
in the Libtool manual: the library is compatible with a library that has
a version number of 1.0.0; if both versions exist, the runtime linker
will prefer the one with the higher middle number (more precisely: the
glibc ldconfig utility will cause the symlink to point to
the file with the highest X in that directory).

* John Calcote wrote on Wed, May 06, 2009 at 06:04:20PM CEST:
> Thanks Andreas. This is excellent information, but I'd like to  
> understand why this is so. Can you point me to a reference that  
> describes this transformation, and perhaps it's rationale?

John, please note that the mapping from -version-info A:B:C to system-
specific version numbers is one where all that libtool guarantees is to
try to map semantics as good as possible.  It does not guarantee that it
maps to a library with major version A or A-C or anything.  It also does
not guarantee that major versions are used consecutively.  Of course it
does not do weird things on purpose, but there are lots of possible
mappings.  For example, one thing libtool does is add 1 on systems where
numbers may not be zero.  For another example, if you move from 2:0:1 to
3:0:0, your Linux version will jump from 1.1.0 to 3.0.0.  That's ok, as
there are lots of integers left for remaining major version numbers.


reply via email to

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