From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id E2406431FD0 for ; Thu, 29 Sep 2011 13:13:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPEK13zfmrtr for ; Thu, 29 Sep 2011 13:13:16 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by olra.theworths.org (Postfix) with ESMTP id 5DA65431FB6 for ; Thu, 29 Sep 2011 13:13:16 -0700 (PDT) X-AuditID: 12074424-b7ef76d0000008dc-21-4e84d15be9a1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 7D.05.02268.B51D48E4; Thu, 29 Sep 2011 16:13:15 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p8TKDEGo027138; Thu, 29 Sep 2011 16:13:15 -0400 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8TKDDOP005130 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 29 Sep 2011 16:13:14 -0400 (EDT) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72) (envelope-from ) id 1R9N16-00075n-8R; Thu, 29 Sep 2011 16:15:36 -0400 Date: Thu, 29 Sep 2011 16:15:36 -0400 From: Austin Clements To: David Bremner 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) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1o2+2OJn8P6FtsWN1m5Gi+s3ZzI7 MHk8W3WL2WPLoffMAUxRXDYpqTmZZalF+nYJXBk/j+9jLJjLUXG6YTlbA+Mpti5GDg4JAROJ q8djuxg5gUwxiQv31gOFuTiEBPYxSrT+fMwC4WxglNjxbhMThHOSSeLry9dQZUsYJe5PP8kC 0s8ioCrxdEETI4jNJqAhsW3/cjBbBCh+ddtkNhCbWUBa4tvvZiaQ1cICZhKvFsqBhHkFdCT+ r/nNDDHzCqPEpHvHWSESghInZz5hgejVkrjx7yVYL8ic5f84QMKcAroSOx/vBCsXFVCRuLa/ nW0Co9AsJN2zkHTPQuhewMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQTIyis 2V1UdjA2H1I6xCjAwajEwyu4pMVPiDWxrLgy9xCjJAeTkiiv5jmgEF9SfkplRmJxRnxRaU5q 8SFGCQ5mJRHeuDagHG9KYmVValE+TEqag0VJnNdmp4OfkEB6YklqdmpqQWoRTFaGg0NJgrfj AlCjYFFqempFWmZOCUKaiYMTZDgP0PD9IDW8xQWJucWZ6RD5U4yKUuK850ESAiCJjNI8uF5Y 2nnFKA70ijBvA0gVDzBlwXW/AhrMBDT4a2EjyOCSRISUVAOjxxvB07w7eq4m3PJ57fRC80+P DMvKI3xp6xU3HttsMNs7IO9Vw9HcS+/P/PpjoW7uEnL55u8+v8Pdi2x1szO5fOzCgndKzrq2 sOoW72KP+tUcLiL5z//IWqnMYliYw9r1gO3LRUaDxEgjm9C716a69wkyNd2ZsK5oimbzvqz5 XVmnDm4Vm1eoxFKckWioxVxUnAgA9I7tzxYDAAA= Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 20:13:17 -0000 Quoth David Bremner on Sep 29 at 4:59 pm: > On Thu, 29 Sep 2011 10:51:29 -0400, Austin Clements 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.