Bug#123887: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wednesday 02 January 2002 15:01, Matt Zimmerman wrote:
> On Wed, Jan 02, 2002 at 01:18:07PM -0600, Kevin Corry wrote:
> > Basically, we don't want to force the user-interfaces to to be
> > recompiled on every minor change to the engine core that doesn't change
> > any of the external APIs. We only intend to change these APIs across a
> > major version change. At most, new APIs may be added, but existing ones
> > (and their defined functionality) will remain the same. Having the soname
> > include only the major number means the existing binary user-interfaces
> > could be used if a new minor or patch-level version of the engine library
> > appears.
>
> OK, so it sounds like the ABI should be stable enough to do normal library
> versioning. So it should start with libevms.so.0 and increment with each
> major release. You can basically do what you want with the rest of the
> version number (libevms.so.0.x.y or such) to indicate minor revisions, but
> it is not, in general, a good idea to try to make this correspond to a
> software release. libtool has this to say about it:
>
> <quote>
> *_Never_* try to set the interface numbers so that they correspond
> to the release number of your package. This is an abuse that only
> fosters misunderstanding of the purpose of library versions. Instead,
> use the `-release' flag (*note Release numbers::), but be warned that
> every release of your package will not be binary compatible with any
> other release.
> </quote>
>
> The -release flag gives you sonames of the form libfoo-x.y.z.so as we
> discussed earlier, while -version-info (the normal case) lets you specify a
> parameter indicating which interfaces are available in this version of the
> library, and handles the actual library versioning automatically.
Hmmm......
Well, for the time being, I have updated the engine/Engine/Makefile in CVS to
use libevms.so.major as the SONAME. As for the "release" vs "app API" version
numbers, we will have to discuss this some more. Perhaps we will need to come
up with a separate version number just for the app API, similar to how we
have a separate version for the IOCTL interface in the kernel code.
In any case, I'll be looking forward to seeing your automake/libtool setup.
Hopefully it can help us clear up some of these issues.
-Kevin
Reply to: