From owner-freebsd-current Tue Apr 2 16:45:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 4E2AD37B419 for ; Tue, 2 Apr 2002 16:45:19 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020403004514.QIPS15826.rwcrmhc54.attbi.com@peter3.wemm.org> for ; Wed, 3 Apr 2002 00:45:14 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g330jDx32370 for ; Tue, 2 Apr 2002 16:45:13 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id BE53D3808; Tue, 2 Apr 2002 16:45:13 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: cjclark@alum.mit.edu Cc: Terry Lambert , freebsd-current@FreeBSD.ORG, Emiel Kollof Subject: Re: kldxref problem In-Reply-To: <20020401163441.A99214@blossom.cjclark.org> Date: Tue, 02 Apr 2002 16:45:13 -0800 From: Peter Wemm Message-Id: <20020403004513.BE53D3808@overcee.wemm.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Crist J. Clark" wrote: > On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote: > > "Crist J. Clark" wrote: > > > This whole argument ignores what the real problem is. The really > > > correct way to handle this is to use the kldxref(8) built in the > > > 'buildworld' phase. (It's bad form to be using any executables from > > > the base system if we have a full object tree.) Actually using the one > > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better > > > thing to do is to have a version in /usr/obj/usr/src//usr/sbin > > > by making it a crosstool. The failure should not be ignored in this > > > case. > > > > Uh, that doesn't work incredibly well when the machine you > > are on is an x86, and the machine that the buildworld targets > > is, say, the Alpha. > > > > This came up in the first place because it's a cross-envrionment > > issue that needs resolving. The "workaround" exists because the > > workaround cops out on the cross-environment part of the process > > and spits out the warnming, instead. > > An 'installworld' doesn't even come close to working in a cross > environment for a whole variety of reasons, so I don't see the > relevance. It used to. If it no longer works, it should be fixed. I partially do this for cross-architecture builds quite often where the target system is NFS mounted somewhere. kldxref however, does not have any cross capability, and is just a hint mechanism even then. It is not essential to run it. > The situation this question comes up is typically 5-CURRENT builds on > 4-STABLE systems, not in cross-archetecture builds. That is a different set of problems. cross-version builds have always been very trouble-prone. same-version cross builds are far less of a problem. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message