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
