Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
Hello, On Wed, Dec 20, 2017 at 8:01 PM, Masahiro Yamada wrote: > Hi Doug > > 2017-12-21 2:07 GMT+09:00 Doug Anderson : >> Hi, >> >> On Tue, Dec 19, 2017 at 6:29 PM, Masahiro Yamada >> wrote: >>> 2017-12-19 2:17 GMT+09:00 Doug Anderson : 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?) >>> >>> 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. >> >> Are you planning on doing this, or is this something you'd like me to >> attempt? I'm a bit busy in the last two days before I go on Christmas >> break, but I can try to squeeze something like this in since the root >> of the issue is a patch that I authored. Let me know. > > I am busy too these days. > Your contribution is very appreciated. OK, I've attempted this. For anyone that might stumble upon this thread, here are links: * https://patchwork.kernel.org/patch/10128647/ [1/2] kbuild: Require a 'make clean' if we detect gcc changed underneath us * https://patchwork.kernel.org/patch/10128645/ [2/2] kbuild: Don't mess with the .cache.mk when installing >> If this is something you'd like me to do, let me know if you think the >> right solution is to detect the problem and warn the user or if the >> right solution is to just blow away the cache. It would be up to you, >> but I'd tend to go the route of warning the user because: >> >> * The user should almost certainly do a "make clean" to really ensure >> no mismatch between object files. >> >> * I could imagine that trying to invoke "make clean" automatically >> might be complicated. > > I agree with both. > > > When compiler upgrade is detected, > we can terminate building > with a hint message to prompt users to run "make clean" > > >>
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
Hi Doug 2017-12-21 2:07 GMT+09:00 Doug Anderson : > Hi, > > On Tue, Dec 19, 2017 at 6:29 PM, Masahiro Yamada > wrote: >> 2017-12-19 2:17 GMT+09:00 Doug Anderson : >>> 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?) >> >> 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. > > Are you planning on doing this, or is this something you'd like me to > attempt? I'm a bit busy in the last two days before I go on Christmas > break, but I can try to squeeze something like this in since the root > of the issue is a patch that I authored. Let me know. I am busy too these days. Your contribution is very appreciated. > If this is something you'd like me to do, let me know if you think the > right solution is to detect the problem and warn the user or if the > right solution is to just blow away the cache. It would be up to you, > but I'd tend to go the route of warning the user because: > > * The user should almost certainly do a "make clean" to really ensure > no mismatch between object files. > > * I could imagine that trying to invoke "make clean" automatically > might be complicated. I agree with both. When compiler upgrade is detected, we can terminate building with a hint message to prompt users to run "make clean" > >> 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... > > Hrm. That doesn't sound nice. I guess this could be solved by > something like your "no-compiler-targets" patch, but IIUC that didn't > include "install" or
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 >> >> 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. > > 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
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
Hi, On Tue, Dec 19, 2017 at 6:29 PM, Masahiro Yamada wrote: > 2017-12-19 2:17 GMT+09:00 Doug Anderson : >> 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?) > > 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. Are you planning on doing this, or is this something you'd like me to attempt? I'm a bit busy in the last two days before I go on Christmas break, but I can try to squeeze something like this in since the root of the issue is a patch that I authored. Let me know. If this is something you'd like me to do, let me know if you think the right solution is to detect the problem and warn the user or if the right solution is to just blow away the cache. It would be up to you, but I'd tend to go the route of warning the user because: * The user should almost certainly do a "make clean" to really ensure no mismatch between object files. * I could imagine that trying to invoke "make clean" automatically might be complicated. > 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... Hrm. That doesn't sound nice. I guess this could be solved by something like your "no-compiler-targets" patch, but IIUC that didn't include "install" or "module_install". I guess the other option would be to somehow detect "UID=0" specifically and not generate the cache? -Doug
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
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 > > 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. Maybe someone can correct me, but this still sounds like an "incremental" build even if just barely. 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? > 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 >> >
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 : > 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?) 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
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
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
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
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?) 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
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
On 12/18/17 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 Thanks for figuring it out. "make clean" does help. I'm supposed it is an interim approach, right? Regards, Yang
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
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 -- Best Regards Masahiro Yamada
Re: [BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"
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... -- Best Regards Masahiro Yamada