Date: Sat, 24 Nov 2012 13:44:15 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: Nikos Vassiliadis <nvass@gmx.com>, Dimitry Andric <dim@FreeBSD.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: strange buildworld failure Message-ID: <7C31A420-1072-4EB7-A83B-D14195434A16@gmail.com> In-Reply-To: <alpine.GSO.1.10.1211241445110.2164@multics.mit.edu> References: <50AF3509.7070402@gmx.com> <CAE-mSO%2BD-KCbJrYrV4c%2BST4Jz0YNRKWnZD6gode2dMGP33=qWA@mail.gmail.com> <50AFED32.5020005@gmx.com> <alpine.GSO.1.10.1211232138030.2164@multics.mit.edu> <50B0B33F.4060802@FreeBSD.org> <50B0EC5B.1080104@gmx.com> <alpine.GSO.1.10.1211241445110.2164@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 24, 2012, at 11:48 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote: > On Sat, 24 Nov 2012, Nikos Vassiliadis wrote: >=20 >> 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)) cou= ld >>>> 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. :) >>=20 >> 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 t= mux >> terminal and the tmux process was using more CPU time than the build itse= lf, >> so I canceled). What should I use with "make -d" in order to get some bas= ic >> debugging? Or is there another way? >=20 > Most cases I know of where a parallel make fails and a serial make succeed= s are due to incomplete specification of dependencies. This can usually be c= hased down with just a build log, without extra debugging information. I ha= ve only needed to resort to the make debugging outputs when doing more inter= esting 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 earli= er on in the compile. Stating that it was a build dependency issue is probab= ly 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7C31A420-1072-4EB7-A83B-D14195434A16>