From owner-freebsd-current@FreeBSD.ORG Sat Mar 11 07:06:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05AE416A41F; Sat, 11 Mar 2006 07:06:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D84B43D45; Sat, 11 Mar 2006 07:06:40 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k2B76dd4029066; Sat, 11 Mar 2006 02:06:39 -0500 (EST) Date: Sat, 11 Mar 2006 02:06:39 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: current@freebsd.org Subject: Re: RFC: Symbol versioning for libc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2006 07:06:41 -0000 On Sat, 11 Mar 2006, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Tue, 7 Mar 2006 22:19:22 -0500 (EST) > >>>>> Daniel Eischen said: > > eischen> I've been working on symbol versioning libc and have a patch > eischen> that seems to work. It's been tested on x86 with build & > eischen> install world, KDE, mozilla, and firefox, but there may be > eischen> some problems I haven't found yet. These would likely result > eischen> in undefined symbol errors from libraries or applications. > > eischen> I'd like to commit what I have to enable wider testing, but > eischen> turn off symbol versioning by default. I would also like > eischen> re@ to take a look at the version namespace scheme. The > eischen> following was derived from Sun's convention. > > I'm working on upgrading the base version of our resolver in libc to > BIND8's one. bind8? We have bind9 in the contrib tree; don't you want that? Any advantage to making a separate libresolv? But I digress... > We'll have more functions than existing our resolver. > Though it will rename/remove some functions, we'll have compatibility > syms for such functions and symbols to provide binary backward > compatibility. So, it could be MFC'ed. I think that such > compatibility syms can be removed safely using your symbol versioning > stuff once your stuff is activated. Yes, but I was thinking we might need to bump libc version number once we enable symbol versioning, so you can probably remove the compat stuff anyways. The problem with not bumping libc version number is that -stable is going to have libc.so.6 also, and any applications you build on -stable won't have bindings to versioned symbols. If there are no bindings to versioned symbols, the application uses the default symbols. When we enable symbol versioning, the default symbols will always be the latest (newest) symbols. So if you change foo() in -current libc.so.6, that will be the default symbol. The old foo() will still remain under an earlier version, but newly built applications will use the new foo(). So the -stable application on -current's libc.so.6 will use the default version of foo() which is not what you want. Unfortunately, I don't see any way to avoid it. > Which timing is better to be done my work before your commit or > after? Thanks for thinking of me :) I'd like to commit my stuff first, 'cause it's getting hard to play catch up. Once in the tree, you can modify the symbol maps yourself for whatever changes you make. I should be ready in a few days; I just have to do some testing on the other archs. -- DE