[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] Where to get OpenCDK 0.6.5

From: Simon Josefsson
Subject: Re: [gnutls-dev] Where to get OpenCDK 0.6.5
Date: Mon, 29 Oct 2007 11:04:53 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Andreas Metzler <address@hidden> writes:

> On 2007-10-28 Simon Josefsson <address@hidden> wrote:
>> Andreas Metzler <address@hidden> writes:
> [...]
>> > One a sidenote, could you bump the symbol versioning please?
>> Uhm, where?  To what?  Do you mean in libgnutls.vers?
> Yes, which you have already done in 2.1.4 ;-)

Actually, I only bumped the ABI version in

As far as I have understood the libgnutls.vers discussions, there really
won't ever be a time we are going to touch that file.  The only time it
would be relevant would be if we implement backwards compatibility via
versioned symbols, so that an old application will get the old version
of a function and a new application will get the new version of the
function.  But that technique, as far as I understood, is not portable.
And we want to be portable.  So if you want to be portable, you'll have
to bump the ABI version in, for those platforms that
doesn't support dso versioning.  And that would break backwards
compatibility via the libgnutls.vers approach.

Theoretically, I guess we could maintain two ABI versions, one version
for platforms that support libgnutls.vers versioning, and one version
for other platforms.  Then we could make libgnutls.vers work.  But this
is a lot of work for us, and while I understand a ABI break is going to
mean work for packagers, it still is only a one-time cost.  ABI breaks
also allows us to remove deprecated cruft, which in the long run is a
good idea.

I still think there is something rotten in the way shared library
versioning works with libtool.  I suspect I have misunderstood how
libgnutls.vers can be used, but when we discussed it last time, I wasn't
able to find any "official" documentation that said it should be used in
some other way.

I think someone should write a 'Practical guide to shared library
versioning'.  Drepper's PDF is an excellent paper, but it doesn't say
what I as maintainer should do in various situations.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]