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

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2006-09-25 Simon Josefsson <jas at extundo.com> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>> > Both ways to fix the issue (decrement soname or bump symbol versioning)
>> > will break binaries linking against 1.5. Reverting the unnecessary
>> > soname bump seems to be the better alternative.
>
>> Ok, I'm doing this now.  To avoid colliding with gnutls 1.4.x (that
>> use shared library version 13.0.x -- also, most likely there will
>> never be any ABI changes in 1.4.x and thus no so version 13.1.x from
>> that branch), I bumped the so version for gnutls 1.5.2 to 13.1.0.
>
> Hello,
> I am sure the following is obvious to anybody but me: ;-)
>
> Afaict you have now gone from
>                 current revision        age
> 1.4.4           13      9               0
> CVS HEAD        14      0               1

Yup.

> which is libtool's way of saying, "new release, some interfaces have
> been added, none have been removed". As 1.4.4 is in freeze its
> interface should stay stable (unless there some bug requiring to
> change it) and therefore 1.4.x will not "catch up".

Yes.

> You have cheated a little bit because actually 1.5.x does not include
> any new interfaces yet.

Right.  Of course, nobody can tell from the outside whether the
interface did change or not (since they can change internally, as
Werner describes).

I considered using 13, 50, 0 instead, to leave some room for future
1.4.x releases, but it seemed somewhat unclean, and the 14,0, 1
approach generate the same libgnutls.so.13 library name.

>> I glanced through Drepper's howto on writing DSO's again, but it isn't
>> really clear to me whether we are doing the right thing here.  The
>> situation is a bit more complex when you want to avoid collisions
>> between two current branches of the same library too.  It is also not
>> clear how things work on non-GNU/Linux platforms without GNU ld.so.
>
> Depending on the architecture anything might happen I guess, but you
> have given libtool sane information to deal with.
>
> I think this is ok.

We'll leave it as is until someone complains.

/Simon