[gnutls-dev] Re: Symbol versioning in gnutls 1.5.x

[Simon Josefsson]

Andreas Metzler <address@hidden> writes:

> Hello,
> I have just taken a first look at packaging gnuntls 1.5.x and stumbled
> upon this one:
>
> /usr/lib/libgnutls.so.14.0.1: 
> Version definitions:
> 1 0x01 0x0ebdb884 libgnutls.so.14
> 2 0x00 0x091de683 GNUTLS_1_3
>
> /usr/lib/libgnutls.so.13.0.9: 
> Version definitions:
> 1 0x01 0x0ebdb883 libgnutls.so.13
> 2 0x00 0x091de683 GNUTLS_1_3
>
> i.e. gnutls 1.5 uses a different soname than gnutls 1.4.x but the
> symbols are still versioned with GNUTLS_1_3.
>
> Afaiu, this is going to cause exactly the breakage symbol versioning
> is supposed to protect us against: If a binary links against both 1.5
> and 1.4 an runtime (e.g. mutt: linking directly against 1.5 for TLS
> and indirectly against 1.4 though libldap) then symbol clashes happen
> and segfaults might be caused.
>
> Both gnutls-1.5.1/libextra/libgnutls-extra.vers and
> gnutls-1.5.1/lib/libgnutls.vers should be bumped.

Hi, thanks for pointing this out.  I think there is an errors here,
but maybe not the one you point out.  I have some more thoughts, but
let's start with the observation below, which may alter the problem
fundamentally.

There appear to have been no external API/ABI changes between 1.4.x
and 1.5.x.  Thus, bumping the shared library version was probably a
mistake.  Does anyone see any value in bumping it anyway?  I
incremented to avoid having old binaries built against 1.4
automatically linking to 1.5, but now when I think about it, I see no
reason to do this.  I think I should revert it back, so that GnuTLS
1.5.x also uses libgnutls.so.13.

/Simon