From owner-cvs-all@FreeBSD.ORG Tue Aug 28 02:32:03 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 9F37416A419; Tue, 28 Aug 2007 02:32:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5941713C457; Tue, 28 Aug 2007 02:32:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l7S2UPIc007172; Mon, 27 Aug 2007 20:30:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 27 Aug 2007 20:30:29 -0600 (MDT) Message-Id: <20070827.203029.-432838018.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20070828005654.GA50401@dragon.NUXI.org> References: <20070824.213615.146406398.imp@bsdimp.com> <20070828005654.GA50401@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 27 Aug 2007 20:30:26 -0600 (MDT) Cc: src-committers@freebsd.org, alfred@freebsd.org, cvs-all@freebsd.org, deischen@freebsd.org, cvs-src@freebsd.org, yar@comp.chem.msu.su 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: Tue, 28 Aug 2007 02:32:03 -0000 In message: <20070828005654.GA50401@dragon.NUXI.org> "David O'Brien" writes: : On Fri, Aug 24, 2007 at 09:36:15PM -0600, M. Warner Losh wrote: : > In message: : > Daniel Eischen writes: : > : I guess the build system should be more tolerant of this, but : > : there are bound to be problems regardless. I don't see why : > : the install tools can't also either have their own set of : > : libraries (utilizing LD_LIBRARY_PATH) or be built static. : > : > There's much resistance to building everything that the build system : > might be used being build static. It adds too much time and : > complexity to the build system, the opponents say. : : I've never heard an argument against building these bits static. : What's the issue? I thought you were one of the folks making this argument when we last changed the FILE structure and related hangers on. None of the binaries is built static by default, so we'd need to build new versions of them static to make this scheme work. We cannot count on them being static in the release that we're upgrading from. However, if we do build new versions static, then they would depend on the new version of the kernel rather than the current version of the kernel. Warner