bug-libtool
[Top][All Lists]
Advanced

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

Re: Shared library versions


From: Alexandre Oliva
Subject: Re: Shared library versions
Date: 22 Feb 2001 08:24:04 -0300
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)

On Feb 21, 2001, Andrew Clausen <address@hidden> wrote:

> That is SURREAL.  I can't wait to see what 3:0:4 will look like...

3:0:4 is pure non-sense.  From the libtool manual:

CURRENT
     The most recent interface number that this library implements.

REVISION
     The implementation number of the CURRENT interface.

AGE
     The difference between the newest and oldest interfaces that this
     library implements.  In other words, the library implements all the
     interface numbers in the range from number `CURRENT - AGE' to
     `CURRENT'.

See?  It doesn't make sense to have AGE greater than CURRENT.

If you follow the procedure you quoted, step by step, you won't ever
get such a version number.

Don't attempt to guess what the resulting MAJOR and MINOR version
numbers are going to be.  They are not relevant.  If you follow the
procedure, you'll get consistent version numbers, i.e.,
backward-compatible changes will have the same SONAME and
backward-incompatible changes will have different SONAMEs.  That's all
the matters.

>   3. If the library source code has changed at all since the last
>      update, then increment REVISION (`C:R:A' becomes `C:r+1:A').

>   4. If any interfaces have been added, removed, or changed since the
>      last update, increment CURRENT, and set REVISION to 0.

>   5. If any interfaces have been added since the last public release,
>      then increment AGE.

>   6. If any interfaces have been removed since the last public release,
>      then set AGE to 0.

> OK.  This is all very confusing to understand, because rule 3
> clashes with rule 4 (I assume 4 overrides 3), and the rules aren't
> mutually exclusive.

Let me try to rephrase it.

before_release () {
  if (library_has_changed())
    r++;

  if (interfaces_have_changed())
    c++, r=0;

  if (interfaces_have_been_added())
    a++;

  if (interfaces_have_been_removed())
    a=0;
}

> start: (rule 1)
>       libtool=0:0:0,  linux=0.0.0

> add an interface: (rule 4, 5)
>       libtool=1:0:1,  linux=0.1.0

No problem here, right?  0.1 is exactly what you expected for a
release after 0.0 in which you have only added interfaces.

> remove an interface: (rule 4, 6)
>       libtool=2:0:0,  linux=2.0.0

I suppose you'd expect to get the major version number 1 here, right?
I think it would be possible to modify libtool's procedures so as to
get what you want.  For example, we could change step 6 so as to
subtract from CURRENT the value of AGE before step 5, before zeroing
AGE.  But I think there would be corner cases that would force the
introduction of additional clauses in the procedure.  As it is now,
it's simple, and it always works, even though it will skip some major
version numbers.  But, as I wrote before, this doesn't matter.  All
that matters is to have the same MAJOR revision number when binary
compatibility is retained, and different MAJOR revision numbers when
it is not.  You shouldn't think of the MAJOR and MINOR version
numbers; think of CURRENT, REVISION and AGE and everything will be
fine.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



reply via email to

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