From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 15:52:45 2005 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 C8BC116A41F; Mon, 22 Aug 2005 15:52:45 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C8FA43D46; Mon, 22 Aug 2005 15:52:45 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id IBA74465; Mon, 22 Aug 2005 08:52:44 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8BF6F5D07; Mon, 22 Aug 2005 08:52:43 -0700 (PDT) To: Ruslan Ermilov In-reply-to: Your message of "Mon, 22 Aug 2005 12:07:58 +0300." <20050822090758.GA665@ip.net.ua> Date: Mon, 22 Aug 2005 08:52:43 -0700 From: "Kevin Oberman" Message-Id: <20050822155243.8BF6F5D07@ptavv.es.net> Cc: current@freebsd.org Subject: Re: buildworld not using proper build environment 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: Mon, 22 Aug 2005 15:52:45 -0000 > Date: Mon, 22 Aug 2005 12:07:58 +0300 > From: Ruslan Ermilov > > On Sun, Aug 21, 2005 at 09:55:58PM -0700, Kevin Oberman wrote: > > > Date: Sun, 21 Aug 2005 09:16:42 +0200 > > > From: Stefan Farfeleder > > > > > > I think the problem is that the files in lib/libedit include histedit.h > > > with "" instead of <>. This works for NetBSD because they have > > > histedit.h in the same directory. -I. should be dropped from CFLAGS > > > probably too. I once noticed a problem that #include picks up > > > the local term.h instead of the one in [..]/tmp/usr/include. > > > > Dropping -I. breaks 'make depend', so that's not a good way to go. I > > fails to find a LOT of stuff. > > > > I really thought that the would fix it, but it does not > > help. I edited all occurrences of "histedit.h" to , but > > .depend still shows that the files in /usr/obj/usr/src/tmp are used. > > > That's fine, it's what should be used, /usr/obj/usr/src/tmp/usr/include/his> tedit.h. > "diff /usr/obj/usr/src/tmp/usr/include/histedit.h /usr/src/include/histedit> .h" > should be empty. Oops! I missed a 'not' in there. I meant to type: .depend still shows that the files in /usr/obj/usr/src/tmp are NOT used. > > And > > those files are used for everything. All header files listed in .depend > > are in /usr/includeand none are in /usr/obj/usr/src/tmp/include. > > > That means that for some reason "stage 4.1: building includes" wasn't > run or did something odd. It ran. It was clearly logged. And /usr/obj/usr/src/tmp/ was populated properly. > > I then looked at several other .depend files and I don't find any > > indication that the new header files are ever used. > > > > Is my system somehow broken? I have completely removed /usr/obj and done > > a fresh cvsup. I don't seem to find any stale files and would not expect > > to on a system that was a fresh install three weeks ago. I'd just love > > to find where in the makefiles the include environment is set to pull > > header files from the build tree instead of the existing system. > > > The magic is in Makefile.inc1, TOOLS_PREFIX=${WORLDTMP}. The cross-tools > are built with this as a prefix, causing the standard headers to be looked > up in ${WORLDTMP}/usr/include, libraries in ${WORLDTMP}/usr/lib and so on. > > See if there's something odd in your /etc/make.conf, or in your command > line. Or put the compressed output (stdout+stderr) from running the > "make buildworld" command available somewhere for download. ARGH! It was ccache that did me in! Even though I expressly typed "make -DNOCCACHE", ccache was sneaking in somewhere. I commented out all of the ccache section of make.conf and it fixed the problem. Sorry for the wasted bandwidth. If I get a little time, I may try to figure out why ccache did this, but it's not a high priority. Thanks very much for your time! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634