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

[Masahiro Yamada]

2017-12-19 2:17 GMT+09:00 Doug Anderson <dianders@xxxxxxxxxxxx>:
> 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?)

I agree.
When you upgrade your compiler,
you need to remove not only cache files, but also all object files.
So, "make clean" is the most reasonable way.


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

Right.  I think it's a good thing to do.




BTW, "sudo make install" or "sudo make modules_install" could
add some cache entries by super user privilege?

(For example, run build targets with CROSS_COMPILE,
but run install targets without CROSS_COMPILE,
install targets will produce different cache entries.)


If so, "make clean" in normal user privilege
can not remove cache files...




-- 
Best Regards
Masahiro Yamada