GNU Info

(libtool.info)Release numbers

---

Prev: Updating version info Up: Versioning

---

Enter node , (file) or (file)node

Managing release information
============================

   Often, people want to encode the name of the package release into the
shared library so that it is obvious to the user which package their
programs are linked against.  This convention is used especially on
GNU/Linux:

     trick$ ls /usr/lib/libbfd*
     /usr/lib/libbfd.a	    /usr/lib/libbfd.so.2.7.0.2
     /usr/lib/libbfd.so
     trick$

   On `trick', `/usr/lib/libbfd.so' is a symbolic link to
`libbfd.so.2.7.0.2', which was distributed as a part of
`binutils-2.7.0.2'.

   Unfortunately, this convention conflicts directly with libtool's
idea of library interface versions, because the library interface
rarely changes at the same time that the release number does, and the
library suffix is never the same across all platforms.

   So, in order to accommodate both views, you can use the `-release'
flag in order to set release information for libraries which you do not
want to use `-version-info'.  For the `libbfd' example, the next
release which uses libtool should be built with `-release 2.9.0', which
will produce the following files on GNU/Linux:

     trick$ ls /usr/lib/libbfd*
     /usr/lib/libbfd-2.9.0.so     /usr/lib/libbfd.a
     /usr/lib/libbfd.so
     trick$

   In this case, `/usr/lib/libbfd.so' is a symbolic link to
`libbfd-2.9.0.so'.  This makes it obvious that the user is dealing with
`binutils-2.9.0', without compromising libtool's idea of interface
versions.

   Note that this option causes a modification of the library name, so
do not use it unless you want to break binary compatibility with any
past library releases.  In general, you should only use `-release' for
package-internal libraries or for ones whose interfaces change very
frequently.