From owner-cvs-all@FreeBSD.ORG Mon Aug 27 16:09:29 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48AAB16A421; Mon, 27 Aug 2007 16:09:29 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 82ABC13C478; Mon, 27 Aug 2007 16:09:27 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l7RG9HI8072325; Mon, 27 Aug 2007 20:09:17 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l7RG9Hu0072324; Mon, 27 Aug 2007 20:09:17 +0400 (MSD) (envelope-from yar) Date: Mon, 27 Aug 2007 20:09:16 +0400 From: Yar Tikhiy To: "M. Warner Losh" Message-ID: <20070827160916.GN21352@comp.chem.msu.su> References: <1188077596.1853.55.camel@neo.cse.buffalo.edu> <200708270932.31208.jhb@freebsd.org> <20070827.085906.-332187760.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070827.085906.-332187760.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: src-committers@freebsd.org, jhb@freebsd.org, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, eischen@vigrid.com, kensmith@cse.buffalo.edu Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 16:09:29 -0000 On Mon, Aug 27, 2007 at 08:59:06AM -0600, M. Warner Losh wrote: > In message: <200708270932.31208.jhb@freebsd.org> > John Baldwin writes: > > : Yar's changes should go in and before BETA1, but we don't need any compat > : hacks because the compat would be for users that we don't provide compat > : for. > > ALL of Yar's changes should go in, including the versioned symbols. > Since the consequences of this ABI breakage are trivial to mitigate > with symbol versioning, we should do so. We need a dry-run at it to > make sure there are no problems in the process. We also should not > force all our testers right now to go through significant pain and > suffering. They are much less likely to upgrade and continue to test > out new versions of current. Rebuilding all the ports (since it is > hard to know which ones use fts) is hard and time-consuming (even on > my fast machines it takes days to rebuild everything exclusive of > ooo). Although I can appreciate the arguments of Daniel and John now, [thank you John! :-)], this is also a very valid point to consider. I hate to mention it, but symbol versioning appeared literally non-functional due to a bug in the map-generating script when I tried to use it for the first time in the course of the fts(3) hustle. > In short, I think this is the easiest solution to the build problems > that the change will cause given the set of users that are presently > using the head of the tree. Hacking the build system to make the > incompatible change is dangerous and may break other upgrade paths > that are working. Giving users explicit instructions for jumping the > gap would fix the intallworld case, but would still force users to > rebuild all their ports. Adding the versioned symbols introduces a > tiny bit of cruft in the purity of the ABI, but solves the > installworld problem AND the rebuilding the ports problem. Are there > other REAL solutions to the problem I've not considered? I hope I've found a clean way to overcome the problem in our build system. The problem stemmed from using basic tools from the old, pre-installworld system during installworld. The tools were copied just in case to a scratch directory, so it isn't hard to install the newly built versions of the same tools there instead and make them load the new shared libraries available under ${WORLDTMP}. The trick depends on the running kernel being able to run both old and new code, but it's a well-known requirement for installworld over the live system. I'm going to post the patch for review soon. -- Yar