public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sje@cup.hp.com>
To: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Cc: gcc-patches@gcc.gnu.org, Gerald Pfeifer <gerald@pfeifer.com>,
	 binutils@sourceware.org, "H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: PATCH: import move-if-change from gnulib (was: PATCH: PR binutils/12283: bfd/doc doesn't support parallel build)
Date: Fri, 28 Jan 2011 21:12:00 -0000	[thread overview]
Message-ID: <1296249160.12233.50.camel@hpsje.cup.hp.com> (raw)
In-Reply-To: <20110128201452.GM7234@gmx.de>

On Fri, 2011-01-28 at 21:14 +0100, Ralf Wildenhues wrote:

> 
> I have meanwhile added an improved and fixed version of my proposed
> patch to the (more complete) gnulib copy of move-if-change.  See here:
> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/24860/focus=24865
> 
> I hereby propose to just import the gnulib copy into GCC and src,
> http://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/move-if-change
> and document the change in status as below in patches to src/MAINTAINERS
> and GCC www.  (The Autoconf copy of move-if-change has been updated from
> the gnulib one anyway.)
> 
> Any reasons against doing so?
> 
> Thanks,
> Ralf

I have no objection to this change and I think it will fix things on
most platforms but I have found one platform where I still have a
problem.  On hppa*-*-hpux*, compiling the same program twice in a row
does not result in the exact same executable.  So even with this change
the cmp will fail and the build will still abort like it does now.
During a GCC bootstrap build we work around these issues by using:

cmp --ignore-initial=16

to compare stage2 and stage3 bits.  And we also have to do the GCC
compilation with -frandom-seed=fixed-seed to avoid other differences in
object files.

But for some reason doing both of these still didn't get this to work
for me on the hppa platform.  I was still getting failures in the cmp
check, even with the --ignore-initial flag and the use of -frandom-seed
when compiling chew.

I wonder if it would be reasonable to add a configure flag to bfd that
would enforce the chew dependency (--enable-parallel-doc or something
like that).  It would be off by default but if specified then we would
enforce the chew dependency and parallel builds would just work
normally.

  reply	other threads:[~2011-01-28 21:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-02 17:00 PATCH: PR binutils/12283: bfd/doc doesn't support parallel build H.J. Lu
2010-12-02 18:08 ` Ralf Wildenhues
2010-12-02 18:16   ` H.J. Lu
2010-12-02 18:20     ` Ralf Wildenhues
2010-12-02 18:22       ` Ralf Wildenhues
2010-12-02 18:32         ` Ralf Wildenhues
2010-12-02 18:40           ` H.J. Lu
2010-12-02 19:01             ` Ralf Wildenhues
2010-12-19 14:37           ` Ralf Wildenhues
2010-12-19 18:23             ` H.J. Lu
2011-01-27 23:57               ` Steve Ellcey
2011-01-28 20:15                 ` PATCH: import move-if-change from gnulib (was: PATCH: PR binutils/12283: bfd/doc doesn't support parallel build) Ralf Wildenhues
2011-01-28 21:12                   ` Steve Ellcey [this message]
2011-02-12 15:48                   ` Ralf Wildenhues
2011-01-28 23:32               ` PATCH: PR binutils/12283: bfd/doc doesn't support parallel build Steve Ellcey
2011-01-29  9:42                 ` Ralf Wildenhues
2011-01-31 18:33                   ` Steve Ellcey
2011-02-04  6:34                     ` Ralf Wildenhues
2011-02-04 17:51                       ` Andreas Schwab
2011-02-16  0:07                         ` Steve Ellcey
2011-02-16  5:09                           ` Ralf Wildenhues
2011-02-16 18:36                             ` Andreas Schwab
2011-02-05  0:25                       ` Steve Ellcey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1296249160.12233.50.camel@hpsje.cup.hp.com \
    --to=sje@cup.hp.com \
    --cc=Ralf.Wildenhues@gmx.de \
    --cc=binutils@sourceware.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gerald@pfeifer.com \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).