Re: strange buildworld failure

On Nov 24, 2012, at 11:48 AM, Benjamin Kaduk <kaduk_at_MIT.EDU> wrote:

> On Sat, 24 Nov 2012, Nikos Vassiliadis wrote:
> 
>> On 11/24/2012 1:45 PM, Dimitry Andric wrote:
>>> On 2012-11-24 03:38, Benjamin Kaduk wrote:
>>>> Hmm, buildworld is supposed to be parallel-make-safe.
>>>> Perhaps a full log of the failing buildworld (e.g., with script(1)) could
>>>> be posted for analysis?
>>> Well, either a full log, or the tail of the log, as long as it contains
>>> the actual command(s) that failed.  Sometimes it can help to search
>>> backwards with less, or your favorite editor, for the string "error:",
>>> or if there is no such string, searching for other problem indicators.
>>> Also, copies of make.conf and src.conf are often essential in finding
>>> the cause of the problem.  Many build issues are caused by erroneous
>>> settings. :)
>> 
>> By the way, I tried to add some debugging info with the help of make -d A
>> or -d g2 but the amount of logging was excessive(the build was ran in a tmux
>> terminal and the tmux process was using more CPU time than the build itself,
>> so I canceled). What should I use with "make -d" in order to get some basic
>> debugging? Or is there another way?
> 
> Most cases I know of where a parallel make fails and a serial make succeeds are due to incomplete specification of dependencies.  This can usually be chased down with just a build log, without extra debugging information.  I have only needed to resort to the make debugging outputs when doing more interesting things like custom suffix rules or using the SRCS+OBJS magic provided by the system makefiles in unusual ways.

The more likely explanation is that one of the parallel threads died because of enomem, enospc, or a number of other reasons, and it was some time earlier on in the compile. Stating that it was a build dependency issue is probably not a wise idea at this time as we do not have enough data (logs, no -d A required) to substantiate that claim.

Thanks,
-Garrett