Date:   Wed, 20 Dec 2017 08:55:57 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Yang Shi <yang.s@...baba-inc.com>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        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"

Hi,

On Mon, Dec 18, 2017 at 9:22 AM, Yang Shi <yang.s@...baba-inc.com> wrote:
>
>
> 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.

Maybe someone can correct me, but this still sounds like an
"incremental" build even if just barely.  Specifically as the config
changes then pretty much all source code will be compiled, but I don't
_think_ there's any guarantee that every source file will be
recompiled.  AKA: if there's a file whose config isn't changed by the
"allyesconfig" then it will not be recompiled.  Is that correct?



> 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