Date: Wed, 29 Oct 2014 15:47:25 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Gyrd Thane Lange <gyrd-se@thanelange.no>, FreeBSD Current <freebsd-current@freebsd.org>, Mark Johnston <markj@freebsd.org> Subject: Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory) Message-ID: <4C533C42-2919-4E96-856C-FB6369F453FB@gmail.com> In-Reply-To: <1414616599.17308.141.camel@revolution.hippie.lan> References: <20141028235011.543be3ea@onyx.thanelange.no> <1414537299.17308.28.camel@revolution.hippie.lan> <20141029003515.28e26444@onyx.thanelange.no> <CAGHfRMB5y_wwnvDkfr=p-A=a06rb1z74Am9rCk7jOy-_9X4Krg@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Oct 29, 2014, at 14:03, Ian Lepore <ian@FreeBSD.org> 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..=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C533C42-2919-4E96-856C-FB6369F453FB>