From owner-cvs-all@FreeBSD.ORG Tue Aug 28 04:27:36 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 B3E2016A419; Tue, 28 Aug 2007 04:27:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 545C613C45A; Tue, 28 Aug 2007 04:27:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IPsfm-000LDX-Kr; Tue, 28 Aug 2007 07:27:35 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7S4RNwq022731; Tue, 28 Aug 2007 07:27:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l7S4RNaH022728; Tue, 28 Aug 2007 07:27:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Aug 2007 07:27:22 +0300 From: Kostik Belousov To: "M. Warner Losh" Message-ID: <20070828042722.GQ2332@deviant.kiev.zoral.com.ua> References: <20070824.213615.146406398.imp@bsdimp.com> <20070828005654.GA50401@dragon.NUXI.org> <20070827.203029.-432838018.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6wUvnnXCCq76soZt" Content-Disposition: inline In-Reply-To: <20070827.203029.-432838018.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: fa718887f43e9e3967a9d10f43843ba4 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1410 [August 27 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org 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 04:27:36 -0000 --6wUvnnXCCq76soZt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2007 at 08:30:29PM -0600, M. Warner Losh wrote: > 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. > : >=20 > : > 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. > :=20 > : I've never heard an argument against building these bits static. > : What's the issue? >=20 > I thought you were one of the folks making this argument when we last > changed the FILE structure and related hangers on. >=20 > None of the binaries is built static by default, so we'd need to build It seems that toolchain is built static. Even binaries that go into the DESTDIR are static: % file /usr/bin/ld /usr/bin/ld: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), s= tatically linked, stripped The same is true for as, cc, libexec/cc1, make. The list is definitely not exhaustive. > 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. >=20 > Warner --6wUvnnXCCq76soZt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG06QqC3+MBN1Mb4gRAplCAJwLH5ElJZZxM50H5KnDAbu3LlPMHACgrIuo VglV+Bp3oHxuaykEWtj6GxU= =Jz6Z -----END PGP SIGNATURE----- --6wUvnnXCCq76soZt--