Libtool and Shared Library Version numbers

[Christof Petig <christof petig wtal de>]

Hi Tero,  (CCed to Gtk-List)

In correspondance with Marcus Brinkmann (debian maintainer of gtk--,
glade, glade--, perhaps more) I said I was shocked to see a shared
library named 'gtk-1.1.so.0.0.0'. I promised to take a deep look inside
libtool to find out how to fix this. He answered if I could find out how
to set sensible version number, I should tell you first.

So here's my proposal on how to do it ...

First an excurse about libtool's idea of version information:
We start a new library foo with -version-info 0:0:0,
(current:revision:age)
then we add a new feature 1:0:1,
we fix some bugs 1:1:1, and 1:2:1,
we add another feature 2:0:2,
we remove some feature 3:0:0,
bugfixes 3:1:0, 3:2:0,
additions 4:0:1, 5:0:2,
total revision 6:0:0

This would result (on linux) in the library names
libfoo.so.0[.0.0]
libfoo.so.0[.1.0]
libfoo.so.0[.1.1], libfoo.so.0[.1.2],
libfoo.so.0[.2.0]
libfoo.so.3[.0.0]
libfoo.so.3[.0.1], libfoo.so.3[.0.2]
libfoo.so.3[.1.0], libfoo.so.3[.2.0]
libfoo.so.6[.0.0]

Besides the rapidly growing version, there is no negitiva aspect of this
sceme. Incompatibilities are handled well.

Though this number is in no way related to the release number of the
package! You can't tell what package version this library is from and
whether it's up to date. So libtool invented the -release flag.
A good idea ... unless done the way gtk does (IMHO). Gtk started with
version 0:0:0 once Gtk-1.1 was invented (and nobody ever incremented the
version number).

I would propose the following steps:
Take libtools versioning for each individual shared library (it has it's
benefits), Prepend your package release number (via -release, a date
stamp is a good idea for development versions) but fix libtool (1.3) to
not use the release for the soname (which prevents compatible libraries
from different packes to be compatible).

Simply change (within ltconfig of automake 1.3)
 # This must be Linux ELF.
 linux-gnu*)
   version_type=linux
   library_names_spec='${libname}${release}.so.$versuffix
${libname}${release}.s
-  soname_spec='${libname}${release}.so.$major'
+  soname_spec='${libname}.so.$major'
   finish_cmds='PATH="$PATH:/sbin" ldconfig -n $libdir'
   shlibpath_var=LD_LIBRARY_PATH

(this is the way automake 1.2d did it)

But this requires libtool versioning (I think automake changed the
behaviour because nobody incremented the version but the revision, or
even because some folks did like gtk (invent release and reset
versioning).

Sigh!

----------------------------------
Besides, there is another way:

ignore the compatibility tests and nice features and call libtool with
-version {major+minor}:{micro}:{minor}
so that the library is called
libfoo.so.{major}.{minor}.{micro}
which is MUCH better than staying with 0.0.0.

Though this tells the dynamic linker that packages 0.6.2 and 0.9.9 are
binary compatible (which is rubbish!)

----------------------------------
Best way:

Talk more about this topic and invent a real good platform independant
versioning system. Implement this with libtool and wait some months to
let people upgrade automake. ;-)


Waiting for your comments,

       Christof

PS: please consider at least the second way FAST (I offer help).