From: Ken Moffat <zarniwhoop@ntlworld.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Build failure with make-4.0
Date: Mon, 21 Oct 2013 19:22:29 +0100 [thread overview]
Message-ID: <20131021182229.GA20523@milliways> (raw)
In-Reply-To: <20131019095343.GA24209@milliways>
On Sat, Oct 19, 2013 at 10:53:43AM +0100, Ken Moffat wrote:
> On Sat, Oct 19, 2013 at 10:05:10AM +0100, Peter Maydell wrote:
> >
> > Well, the reason would be that nobody in practice will do
> > that. Make should be setting ARFLAGS correctly (as per
> > its documentation) unless you've somehow managed to
> > set ARFLAGS to something incorrect in your environment.
> > If you "unset ARFLAGS" does it work?
> >
> > -- PMM
> I don't normally touch ARFLAGS. Here's a freshly-untarred qemu
> tree.
>
> ken@ac4tv /scratch/ken/tmp/qemu-1.6.1 $echo $ARFLAGS
>
> ken@ac4tv /scratch/ken/tmp/qemu-1.6.1 $unset ARFLAGS
>
> ./configure --prefix=/usr --sysconfdir=/etc --target-list=x86_64-softmmu
> make
>
> AR libfdt/libfdt.a
> ar: two different operation options specified
> Makefile:234: recipe for target 'libfdt/libfdt.a' failed
> make[1]: *** [libfdt/libfdt.a] Error 1
> Makefile:153: recipe for target 'subdir-dtc' failed
> make: *** [subdir-dtc] Error 2
>
I took this to bug-make, but now I'm back here. The first thing in
rules.mak is
# Don't use implicit rules or variables
# we have explicit rules for everything
MAKEFLAGS += -rR
and Paul Smith said -
It's a qemu bug, that just happened to work with make-3.82. By adding
the -R flag they are stating they don't want to use ANY default variable
values. However they are relying on the default variable value for
ARFLAGS to be set. If they want to use -R they should set ARFLAGS to an
acceptable value in their makefile.
In previous versions of GNU make adding those flags wouldn't take effect
in the current instance of make; it would only be in effect in a
sub-make; that bug/mis-feature was fixed in GNU make 4.0. Now adding
those flags in a makefile takes effect immediately, within that same
instance of make. From the NEWS for GNU make 4.0:
* Setting the -r and -R options in MAKEFLAGS inside a makefile now works as
expected, removing all built-in rules and variables, respectively.
Thread starts at
http://lists.gnu.org/archive/html/bug-make/2013-10/msg00151.html
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
next prev parent reply other threads:[~2013-10-21 18:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 22:48 [Qemu-devel] Build failure with make-4.0 Ken Moffat
2013-10-18 23:36 ` Ken Moffat
2013-10-19 9:05 ` Peter Maydell
2013-10-19 9:53 ` Ken Moffat
2013-10-21 18:22 ` Ken Moffat [this message]
2013-10-21 19:37 ` Peter Maydell
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=20131021182229.GA20523@milliways \
--to=zarniwhoop@ntlworld.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 NNTP newsgroup(s).