[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnutls-dev] Re: Symbol versioning in gnutls 1.5.x
From: |
Simon Josefsson |
Subject: |
[gnutls-dev] Re: Symbol versioning in gnutls 1.5.x |
Date: |
Wed, 27 Sep 2006 10:02:16 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) |
Andreas Metzler <address@hidden> writes:
> On 2006-09-25 Simon Josefsson <address@hidden> wrote:
>> Andreas Metzler <address@hidden> 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