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

[Yang Shi]

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.

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