Re: [AD] sonames

[George Foot <gfoot@xxxxxxxxxx>]

On Wed, Oct 17, 2001 at 11:13:52AM +0100, Vincent Penquerc'h wrote:
> > > liballegro.so.3.9.39
> > 
> > That is an apropriate lib name for SONAME=3, MINOR=9.39. 
> > ldconfig would
> > symlink it to liballegro.so.3 and the applications would use this
> > library. When 3.9.40 gets major changes and is no longer compatible,
> > ldconfig would still think it is a newer version of 
> > liballegro.so.3 and
> > symlink 3.9.40 to it. When the application loads -> *BANG*.
> 
> Do you mean that the rt linker will link against it even if there is no
> symlink ??? Or will it symlink it out of authority ?

The loader loads whichever library is named by the soname, which
is usually (for example) liballegro.so.3, which would be
symlinked to the latest liballegro.so.3.* during installing.
The symlinking (that and liballegro.so -> latest version) is
done by ldconfig during a "make install".  So liballegro.so will
always point to the latest version, which will indeed match
liballeg.a (assuming you also build the static version).

> I thought that kind of things would be the responsibility of the install
> target in the lib's makefile, since it is pretty much the only thing
> that knows whether there is or not compatibility, no?

The install target initiates the symlinking by calling ldconfig,
but it's not based on the makefile's knowledge of backward
compatibility -- it's assumed that liballegro.so.3.* are
binary compatible with each other.

Numbering shared library versions in accordance with release
numbers is discouraged by the ELF documentation I read; this is
why $(major_version) exists.  It's meant to increase whenever a
change breaks binary compatibility.  Last time I looked, the
zipup script (or maybe fixver) just incremented it on every
change.  I'm not sure why we stopped using sonames though, was
there a problem with them?  They shouldn't have got in the way
of anything I can think of.

In the end the only problem with matching the numbers is the
inconvenience -- often release numbers are dictated by people in
suits in the Marketing Department, independent of binary
compatibility.  If you want them the same, it's more a matter of
making the release numbers the same as the binary compatibility
numbers, rather than vice versa -- it's silly if Allegro 4 and
the bugfix 4.1 are only prevented from being binary compatible
by the major version number being forced to change.  So you'd
have to call the bugfix 4.0.1 instead, and use 4.0 as the major
version number.  Luckily Allegro has no marketing bods so you're
free to do this if you want to. :)  If so, I'd suggest using
liballegro.so.x.y.z with x.y as the major number (the bit in the
soname) and z as a minor bugfix number.  IIRC this is fine with
ldconfig, but of course I could be wrong.

Then if you want to use Linux-style numbering, 4.0.0 is the
first Allegro 4.0 release, 4.0.1 is a bugfix, and 4.1.0 is the
first WIP.  Technically you can only stay in 4.1.* as long as
binary compatibility is maintained, but since it's WIP this
could be acceptable (the major problem is that when you upgrade
Allegro you have to rebuild all programs using it).  Otherwise,
the next WIP has to be 4.3.0, and you skip the 4.2.0 release.

Or just use 4.odd.* as CVS versions (which still have the above
problem) and let the even releases be what have been known as
WIPs -- i.e. interim versions which less brave people can feel
comfortable trying out.  On the whole, they've never been really
unstable anyway. :)  That means if you want to make a major
stable update, you just say which WIP is stable (e.g. 4.6.0).
Count the Allegro 3 versions (3.0, 3.1, 3.11, no more really)
and you'll see this isn't too bad after all. :)

George