Library versioning woes [WAS Re: Some bugs in Gnome 0.99.0]

["Gary V. Vaughan" <gvaughan oranda demon co uk>]

Elliot Lee wrote:
> 
> On Wed, 23 Dec 1998 11:21:43 +0000, Gary V. Vaughan
> <gvaughan@oranda.demon.co.uk> wrote:
> 
> >It is correct for library versions to be different from package
> >versions.  After all the two things are entirely different.  The
> >package version is used by the developers to track the chronology of
> >the releases, and perhaps whether major or minor changes have
> >happened in *the functionality*.  The library version is used by the
> >dynamic linker (i.e. by the OS) to track *binary compatibility*
> >between releases of an individual shared library.  With libtool
> >generated libraries, for example, the version numbers are used to
> >tell the linker, at run time, whether it can safely load a newer
> >library version in preference to the library the application was
> >compiled with (presumably the old interface must have been
> >maintained, some bugs have been fixed, and maybe some new
> >features which don't break the previous API are present).
> >
> >It is plain wrong to try to force the package version number into
> >the library version number (despite what raster might tell you
> >=)O|).
> 
> Maybe if libtool weren't so horribly broken, we could use sonames as
> they were intended to be used.

Why do you think that libtool is broken?  Library versioning works just
fine here.  I am not sure what you mean by `use sonames as intended',
could you elabourate on that a little for me, please?
 
> Using arbitrary version numbers for libraries only confuses the user
> when they're trying to satisfy dependencies for a package. Instead of
> hacking around libtool deficiencies, someone should fix libtool to
> allow using complex sonames (e.g. libgnome.so.0.99) on systems that
> allow them, and doing workarounds on systems that don't.

If I understand you correctly, you are saying that you think that
libtool's library versioning scheme does not meet your requirements?
You can turn it off altogether if you want, but then you lose the
advantage of being able to upgrade your shared libraries, and not having
to recompile all of the apps that used the previous version when the
library upgrade hasn't broken binary compatibility.

(Forgive me if you already understand this, but it is a little
complicated, and many people are confused about the reasons for libtool
versioning, so here goes:)
I agree that users find it confusing that the library version numbers
are different from the package version numbers, but that is only because
many developers still force the numbers to be (artificially) the same,
once people got used to the difference between the two versioning
schemes, and used the release version number (from rpm, or whatever) to
satisfy dependencies, it would cease to be a problem.  Ncurses does it
right, for example.  GTK does it wrong.
Let us say that version 1.1.10 of gtk is released, which removes some
functions from the API of libgtk.so, and fixes a serious bug in
libgdk.so.  With the current GTK library versioning, these libs will
have sonames, libgtk.so.1.1 and libgdk.so.1.1, the same as the 1.1.9
sonames.  You can't reliably have both sets of libraries installed
because the dynamic linker will load the 1.1.10 shared libraries into
apps that used the 1.1.9 interface.  With libtool versioning, the 1.1.9
libraries might have had sonames libgtk.so.3.1 and libgdk.so.2.5. 
According to the rules libtool uses, gtk has removed part of the API,
and so must increment its major version, but gdk has left the API
untouched so only the micro number is increased, so with 1.1.10 you
would install libraries with sonames libgtk.so.4.0 and libgdk.so.2.5
(though the revision number would be incremented by 1).  This would mean
that with both sets of libraries (form 1.1.9 and 1.1.10) installed, apps
compiled against the 1.1.9 release would pick up the bugfixes in the
1.1.10 libgdk.so without recompilation, and the sonames of the two
libgdk.so libraries would not conflict, so the dynamic linker would be
able to load the newest libgtk.so which supports the same API as the
version the app was compiled with.  All without being forced to
recompile everything, provided you don't mind leaving the old shared
libraries around.  Think how many times libImlib has caused problems
because the soname is not maintained separately, and the dynamic linker
is not given the information it needs to load a compatible version of
the shared library at runtime.

I think perhaps we are misunderstanding each other a little here... can
you explain to me how you want to increment library versions, and what
you are trying to achieve?  I would be happy to fix any bugs you have
found in libtool.

Cheers,
	Gary V. Vaughan

[P.S after 17:00 BST today I am away from email until Jan 6, so I might
be slow to respond]