[getdns-users] [PATCH] Fix libversion numbering

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue May 12 18:16:29 CEST 2015


On Tue 2015-05-12 10:54:15 -0400, Willem Toorop wrote:

> I have to admit that my initial willingness to blindly agree has been
> tempered somewhat when I was notified of the fact that the .so version
> actually does increment on FreeBSD.

hm, i wasn't hoping for blind agreement anyway, so i'm glad you're
thinking more about this :)  I'm surprised that FreeBSD produces a
different .so number, to be honest.  do you mean it produces something
new for libversion 3:3:2 or for the older settings?

> Op 30-04-15 om 12:00 schreef Willem Toorop:
>>> This is worked around in 0.1.8 by another change to GETDNS_LIBVERSION,
>>> but the change isn't correct either, since interfaces have been added
>>> again (in partcular, the GETDNS_TRANSPORT_TLS_* constants have been
>>> added, which affects the API at least, for tools trying to compile
>>> against the newer version).
>
> It affects the API, but not the ABI.  Since .so versions are really
> about the ABI, I am now fairly reluctant to increase current when only
> constants are added.  I believe the addition of a constant is considered
> a source code change in the context of libtool and only the revision
> needs to be updated.

I think you may be right, but this is not the clearest distinction; in
particular, i think that you could legitimately define an ABI
differently and maybe come to a different conclusion.  There are some
constants that could be added in such a way that i think should
increment the ABI.

What happens if i pass the GETDNS_TRANSPORT_TLS_* constants to a version
of libgetdns that doesn't know about them?  If they were silently
accepted (i don't think this is the case), then this is definitely an
ABI change, because the intended semantics of the underlying library
function have shifted.  If they cause an error (which i think is what
actually happens here, though i haven't tested) then you've got a
stronger argument that the ABI is stable because the semantics are
stable.

> So based on the exposed symbols in the .so, I've done the following
> adaptation to configure.ac.
>
> diff --git a/configure.ac b/configure.ac
> index 6e321ee..b1efccd 100755
> --- a/configure.ac
> +++ b/configure.ac
> @@ -56,10 +56,11 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING
> configured on $CURRENT_DATE for th
>  # getdns-0.1.4 had libversion 0:0:0
>  # getdns-0.1.5 had libversion 1:0:0
>  # getdns-0.1.6 had libversion 1:1:0
> -# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:2:1)
> -# getdns-0.1.8 had libversion 1:3:0 (but should have had 3:3:2)
> +# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:0:1)
> +# getdns-0.1.8 had libversion 1:3:0 (but should have had 2:1:1)
> +# getdns-0.1.9 will have libversion 2:2:1
>  #
> -GETDNS_LIBVERSION=3:3:2
> +GETDNS_LIBVERSION=2:2:1
>
>  AC_SUBST(GETDNS_COMPILATION_COMMENT)
>  AC_SUBST(GETDNS_LIBVERSION)

I think this is OK.  Thanks for thinking it over!

  --dkg


More information about the Users mailing list