Date: Thu, 29 Sep 2011 16:15:36 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: David Bremner <david@tethera.net>
Subject: Re: Concerns regarding some library functions
Message-ID: <20110929201536.GF17905@mit.edu>
References: <871uv2unfd.fsf@gmail.com> <87fwjhx6p5.fsf@convex-new.cs.unb.ca>
	<20110927224622.GR17905@mit.edu> <877h4tyug1.fsf@gmail.com>
	<20110929145129.GB17905@mit.edu> <8762kbqfvv.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8762kbqfvv.fsf@zancas.localnet>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth David Bremner on Sep 29 at  4:59 pm:
> On Thu, 29 Sep 2011 10:51:29 -0400, Austin Clements <amdragon@MIT.EDU> wrote:
> 
> > Yes.  We could just deal with that (there aren't *that* many API
> > consumers).  For binary compatibility, I suppose we could even use
> > symbol versioning.
> 
> I noticed a similar remark in lib/Makefile.local. But I'm not sure how
> this work if the interface of a given library function changed.  Can
> someone point me to some more explanation? 

With symbol versioning we'd still provide the old function (presumably
re-implemented in terms of the new function).  Both would wind up in
the .so and old binaries would still link against the old symbol.  It
doesn't help that much once something gets recompiled; assuming the
source isn't requesting a specific version of a symbol, it will try to
use the latest version.

That, however, is about the extent of my knowledge on symbol
versioning.  It's possible this simply doesn't work with symbols that
don't already have a version; I'm not sure.