Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"

[Masahiro Yamada]

2017-12-21 1:55 GMT+09:00 Doug Anderson <dianders@xxxxxxxxxxxx>:
> Hi,
>
> On Mon, Dec 18, 2017 at 9:22 AM, Yang Shi <yang.s@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
>>>>
>>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada
>>>> <yamada.masahiro@xxxxxxxxxxxxx>:
>>>>>
>>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <yang.s@xxxxxxxxxxxxxxx>:
>>>>>>
>>>>>> 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.

Right.  "git pull && make" is surely incremental build.

>  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?

If some CONFIG options are changes,
only relevant files are re-compiled.
(scripts/basic/fixdep takes care of this)


>
>
>> 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
>>>
>>



-- 
Best Regards
Masahiro Yamada