Re: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wed, Jan 02, 2002 at 01:18:07PM -0600, Kevin Corry wrote:
> What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the
> filename for the library (where x is the version major number, y is minor,
> and z is patchlevel)? This seems to be common on many of the libraries on
> my system.
It all comes down to binary compatibility. In the end, the shared library
versioning scheme does not necessarily have any relationship to the version
numbering of the software, and in the most correct case, it necessarily does
not.
If the soname is libevms.so.x, then any binary compiled against a given x
must be able to link and run correctly with any other (to be practical,
newer) version of libevms which will provide /usr/lib/libevms.so.x. If evms
is ready to make that commitment to binary compatibility, then it should
ship /usr/lib/libevms.so.x.y.z, and symlinks /usr/lib/libevms.so.x and
/usr/lib/libevms.so, where y.z denotes revisions that do not break binary
compatibility.
If the interfaces are still changing a lot at this point in development, it
would be wiser to use libevms-a.b.c.so so that no release will be binary
compatible with any other release.
> 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.
--
- mdz
Reply to: