Date:   Tue, 19 Dec 2017 01:22:44 +0800
From:   "Yang Shi" <yang.s@...baba-inc.com>
To:     Doug Anderson <dianders@...omium.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild:
 Add a cache for generated variables"



On 12/18/17 9:17 AM, Doug Anderson wrote:
> Hi,
> 
> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <yamada.masahiro@...ionext.com>:
>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <yang.s@...baba-inc.com>:
>>>> Hi folks,
>>>>
>>>> I just upgraded gcc to 6.4 on my centos 7 machine by Arnd's suggestion. But,
>>>> I ran into the below compile error with 4.15-rc3 kernel:
>>>>
>>>> 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>
>>>>
>>>> I bisected to commit 3298b690b21cdbe6b2ae8076d9147027f396f2b1 ("kbuild: Add
>>>> a cache for generated variables"). Once I revert this commit, kernel build
>>>> is fine.
>>>>
>>>> gcc 4.8.5 is fine to build kernel with this commit.
>>>>
>>>> I'm not quite sure if this is a bug or my gcc install is skewed although it
>>>> can build kernel without that commit since that commit might exacerbate the
>>>> case.
>>>>
>>>> Any hint is appreciated
>>>
>>>
>>> Today, I was also hit with the same error
>>> when I was compiling linux-next.
>>> I am not so sure why this error happens, but
>>> "make clean" will probably fix the problem.
>>>
>>> You need to do "make clean" to blow .cache.mk
>>> when you upgrade your compiler.
>>> This is nasty, though...
>>>
>>
>>
>> I got it.
>>
>> The following line in the top-level Makefile.
>>
>> NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC)
>> -print-file-name=include)
>>
>>
>> If the stale result of -print-file-name is stored in the cache file,
>> the compiler fails to find <stdarg.h>
> 
> Nice catch!  Do you have any idea how we can fix it?  I suppose we
> could add a single (non-cached) call to CC somewhere in there to get
> CC's version and clobber the cache if the version changes.  Is that
> the best approach here?
> 
> In general I remember thinking about the gcc upgrade problem when I
> was first experimenting with the cache.  At the time my assumption was
> that if someone updated their gcc then they really ought to be doing a
> clean anyway (I wasn't sure if the build system somehow enforced this,
> but I didn't think so).  Doing an incremental build after a compiler
> upgrade just seems (to me) to be asking for asking for trouble, or in
> the very least seems like it's not what the user wanted (if you update
> your compiler you almost certainly want it to be used to build all of
> your code, don't you?)

BTW， I didn't do incremental build in my usecase. I pulled Linus's tree, 
then checked out to a new branch, then "make allyesconfig", basically, 
the kernel will be rebuilt from scratch, but compiler cache is kept intact.

Thanks,
Yang

> 
> Even if it's wise to do a clean after a compiler upgrade, it still
> seems pretty non-ideal that a user has to decipher an arcane error
> like this, so it seems like we should see what we can do to detect
> this case for the user and help them out.  Perhaps rather than
> clobbering the cache we should actually suggest that the user run a
> "make clean"?
> 
> 
> -Doug
> 

Powered by blists - more mailing lists