From owner-freebsd-current@FreeBSD.ORG Wed Oct 29 22:47:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 413B75E0; Wed, 29 Oct 2014 22:47:31 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05F4733D; Wed, 29 Oct 2014 22:47:31 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id lj1so4054254pab.8 for ; Wed, 29 Oct 2014 15:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=adayjtGnjEYhqh5sj0mpLjHOyhiZp00bdJ/SWvgP6cg=; b=pdAbUvK5LoWt7Q1+XAKMm3n6mWUPYGJjVyMzkVQomAQ31x4qfUpip6SpJtCVDUbEpq cudwSUtC6lcuDYX3ZMJNzVK3xyu2OtHW28RFXAN2CJYUkxVSKzaDkk/FkOzaKWWgUQin cqlm/RGceWQXj1Y06/SnzTPCJgjMRHC0+TlJeXrxf+s71gG6KEnEq3jPW4vLldVS5dp2 CBvmRCZCdbFM8jRJ3W79awtRhsPrxRDdGmJsZg4n7pu7bgYu+HS+hfhFFVe2sBpd9d2C 6NG1hw36NI3em3Soe8G437Yemo9BUgyyQSTOd41EDCwthLUZbBHVCp6S8M71hrT+u6uE JCww== X-Received: by 10.70.23.133 with SMTP id m5mr13155179pdf.131.1414622850635; Wed, 29 Oct 2014 15:47:30 -0700 (PDT) Received: from [10.222.96.105] (mobile-166-171-121-185.mycingular.net. [166.171.121.185]) by mx.google.com with ESMTPSA id s15sm5235859pdl.90.2014.10.29.15.47.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 15:47:29 -0700 (PDT) References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <20141029012432.41e22c7a@onyx.thanelange.no> <20141029143850.5af41378@onyx.thanelange.no> <1414593742.17308.72.camel@revolution.hippie.lan> <20141029212454.6fcfc3ac@onyx.thanelange.no> <1414616599.17308.141.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1414616599.17308.141.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4C533C42-2919-4E96-856C-FB6369F453FB@gmail.com> X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Date: Wed, 29 Oct 2014 15:47:25 -0700 To: Ian Lepore Cc: Gyrd Thane Lange , FreeBSD Current , Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Wed, 29 Oct 2014 22:47:31 -0000 > On Oct 29, 2014, at 14:03, Ian Lepore wrote: ... > It appears that src/Makefile.inc1 already does the right thing in > regards to building ctconvert as a bootstrap tool when it needs to. Yes and no. The assumption with the version checks is the the tool is presen= t on the base system (which might be invalidated by build options or install= root pruning) and doesn't necessarily need to be rebuilt. It's an optimizat= ion that works in most, but not all cases. This is why make in /Makefile has testcases to ensure that it can bootstrap t= he build properly. >> happen to notice it sooner because I have no ctfconvert installed on >> the host beforehand. Actually, mine is the better situation in that the >> build stopped with an up front error instead of using the wrong >> (possible outdated) tools and introduced other subtle errors. >>=20 >> I believe this is reproducible on anybodys system by deleting/moving >> the ctfconvert tool away from the host, before trying to build a dtrace >> enabled kernel. >=20 > I think you'll find that that is true of any number of programs > in /usr/bin including, for example, cc or ar or ld. Which gets invalidated periodically, ie you can't build current on certain s= table versions. >> I see elsewhere in the thread that Garret and Mark are onto the real >> problem and solution. >=20 > I don't think so. Mark referred to a problem with the wrong version of > ctfconvert, and he said he thought it had been fixed. Your problem > wasn't corrupted files due to wrong-version. >=20 > We must not let this situation turn into some kind of mythology about an > incompatibility that doesn't exist. You reported that a tool was > missing during the build, we know why it was missing, and we know what > to do to make it not be missing anymore. Problem solved. In the simple case yes, but not in our case. Our case involves making fixes t= o ctfconvert, without bumping the osreldate, because we've forked FreeBSD at= a particular point in time. ctfconvert is not compatible between the build h= ost and the src checkout, so our ctf data gets corrupted when the host copy o= f ctfconvert gets run on the binaries. Cheers..=