Re: make release abends with "*** Error code 1"
Woodchuck <[email protected]>
| Newsgroups | gmane.os.netbsd.help |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 19 Jan 2007, Perry E. Metzger wrote: > Woodchuck <[email protected]> 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.