Re: [Corelinux-develop] shared libraries versioning using libtool

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Yes, if you look in ~/corelinux/configure.in  you will see I have this
commented out from previous analysis.

Christophe Prud'homme wrote:
> 
> Hi all,
> 
> I took this from libtool manual
> 
> The plan:
> 
> I- What are library interfaces?
> II- Libtool's versioning system
> III- Updating library version information
> 
> What I propose is,
> 
> let's begin with:
> 
> - CURRENT=0
> - REVISION=0
> - AGE=0
> it is quite sound because corelinux is in a stable state now
> 
> then if
> 
> - code source is changed: REVISION+=1
> - some library interfaces are changed
>   CURRENT += 1 (if existing interfaces are changed)
>   REVISION = 0
> - if any interfaces(ner class) have been added: AGE+=1 (CURRENT has not been increased)
> - if interfaces(remove a member function or a class) have been removed AGE=0 (CURRENT has been increased)
> 
> some scenarios:
> ---------------
> ** if an existing interface is changed then  it means that the library is not binary compatible anymore so
>    CURRENT+=1
> ** if code source is changed then the lib is still binary compatible so just do a REVISION+=1
> ** if a new interface(a new class for example) is added then the lib
>    is still binary compatible but a new interface is available (old
>    code should work) just do an AGE+=1
> 
> comments ?
> have a good reading!
> 
> ================================================================================
> 
> I- What are library interfaces?
> ===============================
> 
>    Interfaces for libraries may be any of the following (and more):
> 
>    * global variables: both names and types
> 
>    * global functions: argument types and number, return types, and
>      function names
> 
>    * standard input, standard output, standard error, and file formats
> 
>    * sockets, pipes, and other inter-process communication protocol
>      formats
> 
>    Note that static functions do not count as interfaces, because they
> are not directly available to the user of the library.
> 
> II- Libtool's versioning system
> ================================
> 
>    Libtool has its own formal versioning system.  It is not as flexible
> as some, but it is definitely the simplest of the more powerful
> versioning systems.
> 
>    Think of a library as exporting several sets of interfaces,
> arbitrarily represented by integers.  When a program is linked against
> a library, it may use any subset of those interfaces.
> 
>    Libtool's description of the interfaces that a program uses is
> simple: it encodes the least and the greatest interface numbers in the
> resulting binary (FIRST-INTERFACE, LAST-INTERFACE).
> 
>    The dynamic linker is guaranteed that if a library supports _every_
> interface number between FIRST-INTERFACE and LAST-INTERFACE, then the
> program can be relinked against that library.
> 
>    Note that this can cause problems because libtool's compatibility
> requirements are actually stricter than is necessary.
> 
>    Say `libhello' supports interfaces 5, 16, 17, 18, and 19, and that
> libtool is used to link `test' against `libhello'.
> 
>    Libtool encodes the numbers 5 and 19 in `test', and the dynamic
> linker will only link `test' against libraries that support _every_
> interface between 5 and 19.  So, the dynamic linker refuses to link
> `test' against `libhello'!
> 
>    In order to eliminate this problem, libtool only allows libraries to
> declare consecutive interface numbers.  So, `libhello' can declare at
> most that it supports interfaces 16 through 19.  Then, the dynamic
> linker will link `test' against `libhello'.
> 
>    So, libtool library versions are described by three integers:
> 
> 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'.
> 
>    If two libraries have identical CURRENT and AGE numbers, then the
> dynamic linker chooses the library with the greater REVISION number.
> 
> III- Updating library version information
> =========================================
> 
>    If you want to use libtool's versioning system, then you must specify
> the version information to libtool using the `-version-info' flag
> during link mode (*note Link mode::).
> 
>    This flag accepts an argument of the form
> `CURRENT[:REVISION[:AGE]]'.  So, passing `-version-info 3:12:1' sets
> CURRENT to 3, REVISION to 12, and AGE to 1.
> 
>    If either REVISION or AGE are omitted, they default to 0.  Also note
> that AGE must be less than or equal to the CURRENT interface number.
> 
>    Here are a set of rules to help you update your library version
> information:
> 
>   1. Start with version information of `0:0:0' for each libtool library.
> 
>   2. Update the version information only immediately before a public
>      release of your software.  More frequent updates are unnecessary,
>      and only guarantee that the current interface number gets larger
>      faster.
> 
>   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.
> 
> [IMPORTANT NOTICE]
> 
>    *_Never_* try to set the interface numbers so that they correspond
> to the release number of your package.  This is an abuse that only
> fosters misunderstanding of the purpose of library versions.  Instead,
> use the `-release' flag (*note Release numbers::), but be warned that
> every release of your package will not be binary compatible with any
> other release.
> 
> regards
> C.
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package