buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory)

Garrett Cooper yaneurabeya at
Wed Oct 29 22:47:31 UTC 2014

> On Oct 29, 2014, at 14:03, Ian Lepore <ian at> 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 present 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 optimization that works in most, but not all cases.

This is why make in /Makefile has testcases to ensure that it can bootstrap the 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.
>> 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.
> 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 stable versions.

>> I see elsewhere in the thread that Garret and Mark are onto the real
>> problem and solution.
> 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.
> 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 to ctfconvert, without bumping the osreldate, because we've forked FreeBSD at a particular point in time. ctfconvert is not compatible between the build host and the src checkout, so our ctf data gets corrupted when the host copy of ctfconvert gets run on the binaries.


More information about the freebsd-current mailing list