Subject: Re: make release abends with "*** Error code 1"
To: Perry E. Metzger <perry@piermont.com>
From: Woodchuck <djv@bedford.net>
List: netbsd-help
Date: 01/19/2007 19:06:02
On Fri, 19 Jan 2007, Perry E. Metzger wrote:

> Woodchuck <djv@bedford.net> writes:
>> On this machine: NetBSD jezebel.chuck 3.1_STABLE NetBSD 3.1_STABLE
>> (GENERIC) #0:
>> 	Wed Jan 17 15:08:30 EST 2007
>>
>> the commands:
>> cd /usr/src
>> make release 2>&1 | tee /home/make.out
>>
>> are failing.  This error is repeatable.
>
> I'd suggest using build.sh instead of "make release". It also looks
> like you may be missing some of the error message information, though
> I'm not sure why.
>
> Perry

Trust me, the sample command above (make release 2>...) is *cut
and pasted* from the command history, and the total output put up
at the website is unedited.

Googling various archives for Net- Free- and OpenBSD show that your
response is a typical one going back several years ;-), namely
"Where are the error messages?" And indeed I share your mystification
about that.  I have the feeling that there is a *bug* somewhere,
and that no error messages are in fact being produced, and that the
bug is either in make or in something else, possibly some shell
script, called by make, which is "stingy" with information, or that
it is invoked with 2>/dev/null, as is sometimes done by the "hurried"
programmer.  I have a another hypothesis that some program or script
is returning an error to make either by failing to properly set its
return code or by returning non-zero through a programming oversight.

I suspect mtree, the command that seemed to have most recently
executed.  A cursory inspection of the source in
/usr/src/usr.sbin/mtree/mtree.c shows this bit of code near the
end:

 	status = verify();
 	if (Uflag & (status == MISMATCHEXIT))
 		status = 0;
 	exit(status);
}

I feel like putting in a spoiler gap here, so that readers could
try to "spot that bug", but I won't ;-)

Long experience suggests to me that the if statement should read
 	if (Uflag && (status == MISMATCHEXIT))
I say that without analyzing the code.

If the bug repeats with build.sh, I'll let the list know.  Then
I'll see about changing mtree.  I have a sense of deja-vu about
mtree and this particular bug, I seem to recall hacking at it many
years ago in a different OS.

I also have a suspicion why this mtree bug, if it is one, doesn't
surface during the make-ing of releases by the core team.

Thanks for your response and encouragement.

Dave
-- 
         In each of us, there burns a soul of a woodchuck.
         In every generation a few are chosen to prove it.