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

[Doug Anderson]

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

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