lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 Dec 2017 12:47:44 +0900
From:   Masahiro Yamada <>
To:     Doug Anderson <>
Cc:     Yang Shi <>, Arnd Bergmann <>,
        Ingo Molnar <>,
        Guenter Roeck <>,
        linux-kernel <>
Subject: Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild:
 Add a cache for generated variables"

2017-12-21 1:55 GMT+09:00 Doug Anderson <>:
> Hi,
> On Mon, Dec 18, 2017 at 9:22 AM, Yang Shi <> wrote:
>> On 12/18/17 9:17 AM, Doug Anderson wrote:
>>> Hi,
>>> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
>>> <> wrote:
>>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada
>>>> <>:
>>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <>:
>>>>>> 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
>>>>> 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

Powered by blists - more mailing lists