Re: [gtk-list] Libtool and Shared Library Version numbers

[Owen Taylor <otaylor redhat com>]

Christof Petig <christof.petig@wtal.de> writes:

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

OK, now why are you "shocked to see a shared library named
'gtk-1.1.so.0.0.0'"?

It is perhaps a little unconventional, but it is, I think, I quite
well thought out, and works well.

If you understand libtools versioning, then the GTK+ approach
is very simple to understand:

 We use libtool's versioning, but start over for each
 major/minor pair.

There is only one significant limitation of the scheme - we
cannot change the package minor (not micro) version number,
and still maintain the "nice" names, and binary compatiblity.

It was our opinion that we were unlikely to want to do this.
Because of the nested structures in GTK+, maintaining binary
compatibility while making significant changes to the library
is very difficult. (If the size of a base-class structure
changes, all widgets derived from it will break)
 
> 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).

Hmmm, the situation is a bit different

1) -release, as implemented in current versions of libtool, cannot be
   used in conjuction with -version-info. To avoid diverging too
   much from the standard libtool, we instead just changed the
   library name; the ability to combine them was going to be added,
   but libtool is apparently been dropped by its maintainer. 
  
   With this situation in mind, we may just go to using a custom
   version of libtool in GTK+, though this can cause problems
   for people who want to use their own libtool.

2) The reason why GTK-1.1 is still on 0:0:0, is not that we don't
   know how to increment the version number, it's because the original
   idea was to just increment the version number whenever we
   made up a release; to avoid having to increment the verseion numbers
   constantly, and to avoid leaving hundreds of shared libraries 
   sitting around people's hard drives. We still haven't made a
   release, so we are still at 0:0:0.
 
> 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).

I don't understand the last parenthetical remark. And it seems that
not using the release for the soname would defeat the purpose.

> 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).

Note:

 libtool is a separate package from automake, and can be gotten
 separately from ftp.gnu.org / alpha.gnu.org

> [ approach of faking things so that package version no's ==
>   shared library version no's ]

> Though this tells the dynamic linker that packages 0.6.2 and 0.9.9 are
> binary compatible (which is rubbish!)
 
You have to take into account that libtool handles things differently
on different systems; this only gives you the "correct" version
numbers on ELF systems, plus you loose the advantages of libtool's
versioning.

Regards,
                                      Owen