From owner-freebsd-current@FreeBSD.ORG Sun Mar 12 18:16:09 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 0E15E16A400; Sun, 12 Mar 2006 18:16:09 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8197443D45; Sun, 12 Mar 2006 18:16:05 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:MURmM2/i7dg6b64PLgQm+HdhnoF2qVgcR3HblR+gg7B3mQ6a+xe4oLzUYKOm0Z+m@kasuga-iwi.mahoroba.org [IPv6:3ffe:501:185b:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id k2CIG0qO014595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2006 03:16:00 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 13 Mar 2006 03:15:59 +0900 Message-ID: From: Hajimu UMEMOTO To: Daniel Eischen In-Reply-To: References: User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.1) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.1-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.3 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Mon, 13 Mar 2006 03:16:01 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ameno.mahoroba.org 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 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2006 18:16:09 -0000 Hi, >>>>> On Sat, 11 Mar 2006 02:06:39 -0500 (EST) >>>>> Daniel Eischen said: deischen> bind8? We have bind9 in the contrib tree; don't you want that? deischen> Any advantage to making a separate libresolv? But I digress... Yup, I meant the resolver in BIND9. Since our resolver is tightly integrated in libc, it is hard to simply separate it to libresolv. Further, our resolver has many changes. So, we cannot just replace our resolver to BIND9's one. However, since res_sendsigned(3) uses MD5 functions, it is hard to include it without having MD5 functions in libc. So, I'll not merge it into libc. And, res_update(3) in BIND9 is not binary compatible with our res_update(3). So, I'll leave our res_update(3) as is. Since, res_update(3) is not essential part of resolver, I think that it should be removed from libc in the future. So, it may better to have libresolv for such functions. deischen> Yes, but I was thinking we might need to bump libc version number deischen> once we enable symbol versioning, so you can probably remove the deischen> compat stuff anyways. Okay, thanks. deischen> The problem with not bumping libc version number is that -stable deischen> is going to have libc.so.6 also, and any applications you build deischen> on -stable won't have bindings to versioned symbols. If there deischen> are no bindings to versioned symbols, the application uses the deischen> default symbols. When we enable symbol versioning, the default deischen> symbols will always be the latest (newest) symbols. So if you deischen> change foo() in -current libc.so.6, that will be the default deischen> symbol. The old foo() will still remain under an earlier version, deischen> but newly built applications will use the new foo(). So the deischen> -stable application on -current's libc.so.6 will use the default deischen> version of foo() which is not what you want. deischen> Unfortunately, I don't see any way to avoid it. I have no idea around here. > Which timing is better to be done my work before your commit or > after? deischen> Thanks for thinking of me :) I'd like to commit my stuff first, deischen> 'cause it's getting hard to play catch up. Once in the tree, deischen> you can modify the symbol maps yourself for whatever changes deischen> you make. I should be ready in a few days; I just have to deischen> do some testing on the other archs. It's okay to wait until your work is finished. But, I'm still wondering if we need to bump symbol version just after your commit. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/