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

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CAK7LNATkecHk=GKuMZ3gGew3co0RGwn6oZv92czxLcQ8wX8VyQ@mail.gmail.com>
Date:   Wed, 20 Dec 2017 11:29:00 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Yang Shi <yang.s@...baba-inc.com>, Arnd Bergmann <arnd@...db.de>,
        Ingo Molnar <mingo@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild:
 Add a cache for generated variables"

2017-12-19 2:17 GMT+09:00 Doug Anderson <dianders@...omium.org>:
> Hi,
>
> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <yamada.masahiro@...ionext.com>:
>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <yang.s@...baba-inc.com>:
>>>> 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