From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937316AbdLRRXS (ORCPT ); Mon, 18 Dec 2017 12:23:18 -0500 Received: from out0-230.mail.aliyun.com ([140.205.0.230]:51957 "EHLO out0-230.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935480AbdLRRXF (ORCPT ); Mon, 18 Dec 2017 12:23:05 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R981e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04463;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---.9loqmil_1513617772; Subject: Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables" To: Doug Anderson , Masahiro Yamada Cc: Arnd Bergmann , Ingo Molnar , Guenter Roeck , linux-kernel References: <8d9a5c09-23e2-253b-860d-7bc9d20f5317@alibaba-inc.com> From: "Yang Shi" Message-ID: <9db2bd33-1ea9-4064-bd2f-3d7a80f6dc69@alibaba-inc.com> Date: Tue, 19 Dec 2017 01:22:44 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>> >>>> 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 > > 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 >