From owner-freebsd-current@FreeBSD.ORG Sat Nov 24 21:44:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09049BD3; Sat, 24 Nov 2012 21:44:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE84A8FC17; Sat, 24 Nov 2012 21:44:17 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so7385389pbc.13 for ; Sat, 24 Nov 2012 13:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=TzkCA/GWpEvQRBhm3V93YobHr4RWlhO2xCYTTY7/S78=; b=rfe5oDT6YE58AvyBGXi6piW4jjmVLBBGL8kOvbae09nOMx3oWOYv5qGHzGNAV9v/xS QnjIzEBwpn5idkjf8g3NkF+9Eia8jG56kRwWx7Nzp3iRE4GwEytg6gepacJqDZPEn5/l v810hHEFrqO5sBhUoitYBgAPphFs51sOiMfapJbLR9zz1/FW/pzVzaby0KGhDi6xwTPH sgVzvHVxeVUQ4zK+vSABe3Ox09ddFmbOElU02PFg4UB3NnbaPevzxEhEGLd43ThXQE/Z tbn2vH07Y5+4vVTGl51mJ+aR0e8WQQ43wPVMHTfBb7JAV9C4fbb6kZcUbpY9i2JuylCr pXWQ== Received: by 10.68.137.131 with SMTP id qi3mr25339504pbb.114.1353793457132; Sat, 24 Nov 2012 13:44:17 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id d2sm5941891paw.19.2012.11.24.13.44.15 (version=SSLv3 cipher=OTHER); Sat, 24 Nov 2012 13:44:15 -0800 (PST) References: <50AF3509.7070402@gmx.com> <50AFED32.5020005@gmx.com> <50B0B33F.4060802@FreeBSD.org> <50B0EC5B.1080104@gmx.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7C31A420-1072-4EB7-A83B-D14195434A16@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: strange buildworld failure Date: Sat, 24 Nov 2012 13:44:15 -0800 To: Benjamin Kaduk Cc: Nikos Vassiliadis , Dimitry Andric , "freebsd-current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 21:44:18 -0000 On Nov 24, 2012, at 11:48 AM, Benjamin Kaduk 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=