[gnutls-devel] symbol and library versioning

[Daniel P. Berrange]

On Thu, Aug 10, 2017 at 01:41:55PM +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Aug 10, 2017 at 11:14 AM, Daniel P. Berrange
> <berrange at redhat.com> wrote:
> > On Thu, Aug 10, 2017 at 10:31:28AM +0200, Nikos Mavrogiannopoulos wrote:
> >> Hi,
> >>  With mind in the upcoming 3.6.0 release I tried to codify/clarify the
> >> library and symbol versioning rules that are considered best practice
> >> today.
> >>
> >> The output is at:
> >> https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md#symbol-and-library-versioning
> >>
> >> My take-away from it, is that the complexity of libtool rules is
> >> unnecessary and in fact all that is being used from it is the major
> >> soname version (thus the minor and patch versions set via libtool are
> >> being used by no software).
> >
> > Yes, libtool versioning is not really useful, especially for a library
> > that intends to maintain API/ABI compat long term / forever.
> 
> I wonder whether there is a reason not to keep the libtool numbers
> fixed, and follow its versioning requirements.

AFAIK, the per-symbol versions offer a superset of the functionality
provided by libtool soname versioning, at least on ELF platforms. If
you care about Windows DLLs or OS-X dynlibs, then perhaps the libtool
versions would have some small benefit, but I don't think its worth it
personally.

> >> The versioning that matters is via the linker script, which is then
> >> used by packaging software like rpm (I guess possibly dpkg as well),
> >> to detect proper dependencies.
> >>
> >> Did I miss something in that? Are there are best practices I missed,
> >> or any issues in the rules I set above?
> >
> > I believe your backporting rule is a bad idea.
> >
> >   "if symbol gnutls_xyz with version GNUTLS_3_6_3 is backported on
> >    gnutls 3.3.15, it should use version GNUTLS_3_3_15."
> >
> > This creates ABI breakage when you upgrade gnutls in the distro. eg
> >
> > An application which links to your gnutls 3.3.15 version and uses
> > symbol gnutls_xyz will get a embedded symbol reference of
> > gnutls_xyz at GNUTLS_3_3_15.   When you then update to gnutls 3.6.3 in
> > the distro, the linker will be unable to resolve gnutls_xyz at GNUTLS_3_3_15,
> > because the library will now be exporting gnutls_xyz at GNUTLS_3_6_3
> > instead.
> 
> Right. Note however that in gnutls we haven't kept ABI compatibility
> over the years and this statement applies to backporting to an
> ABI-incompatible version. Backporting to ABI-compatible versions is
> explicitly disallowed to avoid the issues you describe in your post.

Ok, yes, if you have an .so ELF version  change between those
two versions, then apps need a rebuild already, so the problem
I describe wouldn't hit.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|