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
Regards,
Yang
2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
> 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...
--
Best Regards
Masahiro Yamada
2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>> 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>
--
Best Regards
Masahiro Yamada
On 12/18/17 7:50 AM, Masahiro Yamada wrote:
> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>> 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>
Thanks for figuring it out.
"make clean" does help. I'm supposed it is an interim approach, right?
Regards,
Yang
>
>
Hi,
On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
<[email protected]> wrote:
> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>> 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?)
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
On 12/18/17 9:17 AM, Doug Anderson wrote:
> Hi,
>
> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
> <[email protected]> wrote:
>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>>> 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
>
2017-12-19 2:17 GMT+09:00 Doug Anderson <[email protected]>:
> Hi,
>
> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
> <[email protected]> wrote:
>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>>> 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
Hi,
On Mon, Dec 18, 2017 at 9:22 AM, Yang Shi <[email protected]> wrote:
>
>
> On 12/18/17 9:17 AM, Doug Anderson wrote:
>>
>> Hi,
>>
>> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
>> <[email protected]> wrote:
>>>
>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada
>>> <[email protected]>:
>>>>
>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>>>>
>>>>> 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.
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
>>
>
Hi,
On Tue, Dec 19, 2017 at 6:29 PM, Masahiro Yamada
<[email protected]> wrote:
> 2017-12-19 2:17 GMT+09:00 Doug Anderson <[email protected]>:
>> Hi,
>>
>> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
>> <[email protected]> wrote:
>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>>>> 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.
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
2017-12-21 1:55 GMT+09:00 Doug Anderson <[email protected]>:
> Hi,
>
> On Mon, Dec 18, 2017 at 9:22 AM, Yang Shi <[email protected]> wrote:
>>
>>
>> On 12/18/17 9:17 AM, Doug Anderson wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
>>> <[email protected]> wrote:
>>>>
>>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada
>>>> <[email protected]>:
>>>>>
>>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>>>>>
>>>>>> 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.
>
> 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
Hi Doug
2017-12-21 2:07 GMT+09:00 Doug Anderson <[email protected]>:
> Hi,
>
> On Tue, Dec 19, 2017 at 6:29 PM, Masahiro Yamada
> <[email protected]> wrote:
>> 2017-12-19 2:17 GMT+09:00 Doug Anderson <[email protected]>:
>>> Hi,
>>>
>>> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
>>> <[email protected]> wrote:
>>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
>>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>>>>> 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.
>
> 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 "module_install". I guess the other option would
> be to somehow detect "UID=0" specifically and not generate the cache?
>
> -Doug
That would be a solution.
We can skip cache generation for some sort of targets.
--
Best Regards
Masahiro Yamada
Hello,
On Wed, Dec 20, 2017 at 8:01 PM, Masahiro Yamada
<[email protected]> wrote:
> Hi Doug
>
> 2017-12-21 2:07 GMT+09:00 Doug Anderson <[email protected]>:
>> Hi,
>>
>> On Tue, Dec 19, 2017 at 6:29 PM, Masahiro Yamada
>> <[email protected]> wrote:
>>> 2017-12-19 2:17 GMT+09:00 Doug Anderson <[email protected]>:
>>>> Hi,
>>>>
>>>> On Mon, Dec 18, 2017 at 7:50 AM, Masahiro Yamada
>>>> <[email protected]> wrote:
>>>>> 2017-12-18 23:56 GMT+09:00 Masahiro Yamada <[email protected]>:
>>>>>> 2017-12-17 7:35 GMT+09:00 Yang Shi <[email protected]>:
>>>>>>> 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.
>>
>> 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"
>
>
>>
>>> 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
>
> That would be a solution.
> We can skip cache generation for some sort of targets.
When I thought about this and tested, I realized that this is a pretty
unlikely scenario to run into (and also it's somewhat obvious what is
happening). ...but I've posted up a patch in any case so you can see
what you think. ;)
-Doug