From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-68935-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 21200 invoked by alias); 2 Dec 2010 18:16:14 -0000
Received: (qmail 21191 invoked by uid 22791); 2 Dec 2010 18:16:14 -0000
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Dec 2010 18:16:09 +0000
Received: by qwd6 with SMTP id 6so57857qwd.0        for <binutils@sourceware.org>; Thu, 02 Dec 2010 10:16:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.46.91 with SMTP id i27mr323573qaf.15.1291313767941; Thu, 02 Dec 2010 10:16:07 -0800 (PST)
Received: by 10.220.61.13 with HTTP; Thu, 2 Dec 2010 10:16:07 -0800 (PST)
In-Reply-To: <20101202180829.GA16143@gmx.de>
References: <20101202170032.GA19376@intel.com>	<20101202180829.GA16143@gmx.de>
Date: Thu, 02 Dec 2010 18:16:00 -0000
Message-ID: <AANLkTikDiv+z6DtpZ8DT64gKDtcxsdycJVdNwbExCs7-@mail.gmail.com>
Subject: Re: PATCH: PR binutils/12283: bfd/doc doesn't support parallel build
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Cc: binutils@sourceware.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <binutils.sourceware.org>
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
X-SW-Source: 2010-12/txt/msg00083.txt.bz2

On Thu, Dec 2, 2010 at 10:08 AM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> w=
rote:
> Hello H.J.,
>
> * H.J. Lu wrote on Thu, Dec 02, 2010 at 06:00:32PM CET:
>> Any objection to this patch?
>
> The rule to update $(MKDOC):
>
> $(MKDOC): $(srcdir)/chew.c
> =A0 =A0 =A0 =A0$(CC_FOR_BUILD) -o chew.$$$$ $(CFLAGS_FOR_BUILD) $(LDFLAGS=
_FOR_BUILD) \
> =A0 =A0 =A0 =A0 =A0$(H_CFLAGS) $(AM_CPPFLAGS) $(srcdir)/chew.c; \
> =A0 =A0 =A0 =A0$(SHELL) $(srcdir)/../../move-if-change chew.$$$$ $(MKDOC)
>
> should be atomic (the ';' should be '&&' though). =A0So, I would be

Failure is very random. There is a race condition. "make -j8" on a 16core
machine can start making $(MKDOC) at the same time. How can move-if-change
be 100% atomic?

> interested to see the last 100 or so lines of a failure happening,
> because I can't spot one nor reproduce it. =A0Also, configure flags.
>

--=20
H.J.