[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=UZd7VMuo+amjLZjuT-pFfAYc2hOPLL=U5VXSBJxW53LQ@mail.gmail.com>
Date: Fri, 22 Dec 2017 14:15:33 -0800
From: Doug Anderson <dianders@...omium.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Masahiro Yamada <yamada.masahiro@...ionext.com>,
Mathieu Malaterre <malat@...ian.org>,
Dave Hansen <dave.hansen@...el.com>,
Yang Shi <yang.s@...baba-inc.com>,
Matthias Kaehlcke <mka@...omium.org>,
Cao jin <caoj.fnst@...fujitsu.com>,
Arnd Bergmann <arnd@...db.de>,
Mark Charlebois <charlebm@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 1/2] kbuild: Require a 'make clean' if we detect gcc
changed underneath us
Hi,
On Fri, Dec 22, 2017 at 1:58 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> On Thu, Dec 21, 2017 at 05:53:02PM -0800, Douglas Anderson wrote:
>> Several people reported that the commit 3298b690b21c ("kbuild: Add a
>> cache for generated variables") caused them problems when they updated
>> gcc versions. Specifically the reports all looked something similar
>> to this:
>>
>> > In file included from ./include/uapi/linux/uuid.h:21:0,
>> > from ./include/linux/uuid.h:19,
>> > from ./include/linux/mod_devicetable.h:12,
>> > from scripts/mod/devicetable-offsets.c:2:
>> > ./include/linux/string.h:8:20: fatal error: stdarg.h: No such file or
>> > directory
>> > #include <stdarg.h>
>>
>> Masahiro Yamada determined that the problem was with:
>>
>> NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC)
>> -print-file-name=include)
>>
>> Specifically that the stale result of -print-file-name is stored in
>> the cache file. It was determined that a "make clean" fixed the
>> problems in all cases.
>>
>> In this particular case we could certainly try to clean just the cache
>> when we detect a gcc update, but it seems like overall it's a bad idea
>> to do an incremental build when gcc changes. We should warn the user
>> and tell them that they need a 'make clean'.
>>
>> Fixes: 3298b690b21c ("kbuild: Add a cache for generated variables")
>> Reported-by: Yang Shi <yang.s@...baba-inc.com>
>> Reported-by: Dave Hansen <dave.hansen@...el.com>
>> Reported-by: Mathieu Malaterre <malat@...ian.org>
>> Signed-off-by: Douglas Anderson <dianders@...omium.org>
>
> Unfortunately, it doesn't work as-is. Trying to build for mips with two
> different compilers, and trying to run "make clean" with the 2nd compiler
> version, results in:
>
> scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
> Please 'make clean'. Stop.
> Makefile:1297: recipe for target '_clean_.' failed
> make: *** [_clean_.] Error 2
> make: *** Waiting for unfinished jobs....
> scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
> Please 'make clean'. Stop.
> Makefile:1297: recipe for target '_clean_arch/mips' failed
> make: *** [_clean_arch/mips] Error 2
> scripts/Kbuild.include:490: *** Detected new CC version (050400 vs 040803).
> Please 'make clean'. Stop.
> Makefile:1297: recipe for target '_clean_arch/mips/boot/dts' failed
> make: *** [_clean_arch/mips/boot/dts] Error 2
> make: *** wait: No child processes. Stop.
Indeed. I tried poking around myself today and I clearly saw this
too. I believe I was just doing very simple test cases of "make help"
/ "make clean" yesterday and I thought that would be fine as a
testcase, but clearly not. When I did a more normal make it was easy
to reproduce this.
Poking around it looks like MAKECMDGOALS is somehow blank sometimes as
part of a "make clean". I'll post a v2 that prevents showing the
error in that case too. I'll repeat the caveat that's in my cover
letter that I'm a little lost when it comes to MAKECMDGOALS and how
they get set in all cases, so hopefully this is the right fix.
Sorry for the noise.
I'm going to go ahead and post v2 today even though perhaps not
everyone is done looking at v1. This is because I'll soon disappear
on vacation and I'd rather have a possible fix out there. Hopefully
that's OK w/ everyone.
-Doug
Powered by blists - more mailing lists