| Message ID | 20171003204839.27551-2-dianders@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Oct 3, 2017 at 1:48 PM, Douglas Anderson <dianders@chromium.org> wrote: > The main Linux Makefiles and the tools sub-Makefiles have different > conventions for passing in CC / CFLAGS. > > Here's brief summary for the kernel: > * CC: target C compiler (must be passed as an argument to make to > override) > * HOSTCC: host C compiler (must be passed as an argument to make to > override) > * CFLAGS: ignored (kernel manages its own CFLAGS) > * KCFLAGS: extra cflags for the target (expected as an env var) > * HOSTCFLAGS: host C compiler flags (not modifiable by the caller of > make) > > Here's a brief summary for the tools: > * CC: host C compiler (must be passed as an argument to make to > override) > * CFLAGS: base arguments for the host C compiler which are added to by > sub builds (expected as an env var) > > When the main kernel Makefile calls into the tools Makefile, it should > adapt things from its syntax to the tools Makefile syntax. > > If we don't do this, we have a few issues: > * If someone wants to user another compiler (like clang, maybe) for > hostcc then the tools will still be compiled with gcc. > * If you happen to be building and you left ${CFLAGS} set to something > random (maybe it matches ${CC}, the _target_ C compiler, not the > _host_ C compiler) then this random value will be used to compile > the tools. > > In any case, it seems like it makes sense to pass CC, CFLAGS, and > similar properly into the tools Makefile. > > NOTE: in order to do this properly, we need to add some new > definitions of HOSTAS and HOSTLD into the main kernel Makefile. If we > don't do this and someone overrides "AS" or "LD" on the command line > then those (which were intended for the target) will be used to build > host side tools. We also make up some imaginary "HOSTASFLAGS" and > "HOSTLDFLAGS". Someone could specify these, but if they don't at > least these blank variables will properly clobber ASFLAGS and LDFLAGS > from the kernel. > > This was discovered in the Chrome OS build system where CFLAGS (an > environment variable) was accidentally left pointing to flags that > would be an appropriate match to CC. The kernel didn't use these > CFLAGS so it was never an issue. Turning on STACKVALIDATION, however, > suddenly invoked a tools build that blew up. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> Still not sure if I'd want to go that far. Just clearing out CFLAGS would have fixed my problem, and I start to realize that I am more of a minimalist when it comes to kernel changes. Anyway, not that it means much, Reviewed-by: Guenter Roeck <groeck@chromium.org> Tested-by: Guenter Roeck <groeck@chromium.org> [ I didn't test all possible flag combinations, only a few of them, but I did make sure that "make allmodconfig; CFLAGS=-junk make" no longer fails. ] Guenter > --- > > Makefile | 30 ++++++++++++++++++++++++++++-- > 1 file changed, 28 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index cf007a31d575..0d3af0677d88 100644 > --- a/Makefile > +++ b/Makefile > @@ -298,7 +298,9 @@ HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS) > HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS) > HOST_LFS_LIBS := $(shell getconf LFS_LIBS) > > +HOSTAS = as > HOSTCC = gcc > +HOSTLD = ld > HOSTCXX = g++ > HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ > -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) > @@ -1616,11 +1618,35 @@ image_name: > # Clear a bunch of variables before executing the submake > tools/: FORCE > $(Q)mkdir -p $(objtree)/tools > - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ > + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ > + LDFLAGS="$(HOSTLDFLAGS)" \ > + CFLAGS="$(HOSTCFLAGS)" \ > + CXXFLAGS="$(HOSTCXXFLAGS)" \ > + $(MAKE) \ > + AS="$(HOSTAS)" \ > + CC="$(HOSTCC)" \ > + CXX="$(HOSTCXX)" \ > + LD="$(HOSTLD)" \ > + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ > + O=$(abspath $(objtree)) \ > + subdir=tools \ > + -C $(src)/tools/ > > tools/%: FORCE > $(Q)mkdir -p $(objtree)/tools > - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ $* > + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ > + LDFLAGS="$(HOSTLDFLAGS)" \ > + CFLAGS="$(HOSTCFLAGS)" \ > + CXXFLAGS="$(HOSTCXXFLAGS)" \ > + $(MAKE) \ > + AS="$(HOSTAS)" \ > + CC="$(HOSTCC)" \ > + CXX="$(HOSTCXX)" \ > + LD="$(HOSTLD)" \ > + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ > + O=$(abspath $(objtree)) \ > + subdir=tools \ > + -C $(src)/tools/ $* > > # Single targets > # --------------------------------------------------------------------------- > -- > 2.14.2.920.gcf0c67979c-goog > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2017-10-04 5:48 GMT+09:00 Douglas Anderson <dianders@chromium.org>: > The main Linux Makefiles and the tools sub-Makefiles have different > conventions for passing in CC / CFLAGS. > > Here's brief summary for the kernel: > * CC: target C compiler (must be passed as an argument to make to > override) > * HOSTCC: host C compiler (must be passed as an argument to make to > override) > * CFLAGS: ignored (kernel manages its own CFLAGS) > * KCFLAGS: extra cflags for the target (expected as an env var) > * HOSTCFLAGS: host C compiler flags (not modifiable by the caller of > make) > > Here's a brief summary for the tools: > * CC: host C compiler (must be passed as an argument to make to > override) > * CFLAGS: base arguments for the host C compiler which are added to by > sub builds (expected as an env var) > > When the main kernel Makefile calls into the tools Makefile, it should > adapt things from its syntax to the tools Makefile syntax. > > If we don't do this, we have a few issues: > * If someone wants to user another compiler (like clang, maybe) for > hostcc then the tools will still be compiled with gcc. > * If you happen to be building and you left ${CFLAGS} set to something > random (maybe it matches ${CC}, the _target_ C compiler, not the > _host_ C compiler) then this random value will be used to compile > the tools. > > In any case, it seems like it makes sense to pass CC, CFLAGS, and > similar properly into the tools Makefile. > > NOTE: in order to do this properly, we need to add some new > definitions of HOSTAS and HOSTLD into the main kernel Makefile. If we > don't do this and someone overrides "AS" or "LD" on the command line > then those (which were intended for the target) will be used to build > host side tools. We also make up some imaginary "HOSTASFLAGS" and > "HOSTLDFLAGS". Someone could specify these, but if they don't at > least these blank variables will properly clobber ASFLAGS and LDFLAGS > from the kernel. > > This was discovered in the Chrome OS build system where CFLAGS (an > environment variable) was accidentally left pointing to flags that > would be an appropriate match to CC. The kernel didn't use these > CFLAGS so it was never an issue. Turning on STACKVALIDATION, however, > suddenly invoked a tools build that blew up. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > Makefile | 30 ++++++++++++++++++++++++++++-- > 1 file changed, 28 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index cf007a31d575..0d3af0677d88 100644 > --- a/Makefile > +++ b/Makefile > @@ -298,7 +298,9 @@ HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS) > HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS) > HOST_LFS_LIBS := $(shell getconf LFS_LIBS) > > +HOSTAS = as > HOSTCC = gcc > +HOSTLD = ld > HOSTCXX = g++ > HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ > -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) > @@ -1616,11 +1618,35 @@ image_name: > # Clear a bunch of variables before executing the submake > tools/: FORCE > $(Q)mkdir -p $(objtree)/tools > - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ > + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ > + LDFLAGS="$(HOSTLDFLAGS)" \ > + CFLAGS="$(HOSTCFLAGS)" \ > + CXXFLAGS="$(HOSTCXXFLAGS)" \ > + $(MAKE) \ > + AS="$(HOSTAS)" \ > + CC="$(HOSTCC)" \ > + CXX="$(HOSTCXX)" \ > + LD="$(HOSTLD)" \ > + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ > + O=$(abspath $(objtree)) \ > + subdir=tools \ > + -C $(src)/tools/ > > tools/%: FORCE > $(Q)mkdir -p $(objtree)/tools > - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ $* > + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ > + LDFLAGS="$(HOSTLDFLAGS)" \ > + CFLAGS="$(HOSTCFLAGS)" \ > + CXXFLAGS="$(HOSTCXXFLAGS)" \ > + $(MAKE) \ > + AS="$(HOSTAS)" \ > + CC="$(HOSTCC)" \ > + CXX="$(HOSTCXX)" \ > + LD="$(HOSTLD)" \ > + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ > + O=$(abspath $(objtree)) \ > + subdir=tools \ > + -C $(src)/tools/ $* > Please do not do this. CC: for building tools that run on the target machine HOSTCC: for building tools that run on the build machine IMHO, this should be consistent to avoid confusion. Grepping CROSS_COMPILE under tools/ directory, I see many Makefile expect CC for the target system. For ex, tools/croup/Makefile CC = $(CROSS_COMPILE)gcc Why don't you fix tools/objtool/Makefile ?
On Tue, Oct 3, 2017 at 8:20 PM, Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > 2017-10-04 5:48 GMT+09:00 Douglas Anderson <dianders@chromium.org>: >> The main Linux Makefiles and the tools sub-Makefiles have different >> conventions for passing in CC / CFLAGS. >> >> Here's brief summary for the kernel: >> * CC: target C compiler (must be passed as an argument to make to >> override) >> * HOSTCC: host C compiler (must be passed as an argument to make to >> override) >> * CFLAGS: ignored (kernel manages its own CFLAGS) >> * KCFLAGS: extra cflags for the target (expected as an env var) >> * HOSTCFLAGS: host C compiler flags (not modifiable by the caller of >> make) >> >> Here's a brief summary for the tools: >> * CC: host C compiler (must be passed as an argument to make to >> override) >> * CFLAGS: base arguments for the host C compiler which are added to by >> sub builds (expected as an env var) >> >> When the main kernel Makefile calls into the tools Makefile, it should >> adapt things from its syntax to the tools Makefile syntax. >> >> If we don't do this, we have a few issues: >> * If someone wants to user another compiler (like clang, maybe) for >> hostcc then the tools will still be compiled with gcc. >> * If you happen to be building and you left ${CFLAGS} set to something >> random (maybe it matches ${CC}, the _target_ C compiler, not the >> _host_ C compiler) then this random value will be used to compile >> the tools. >> >> In any case, it seems like it makes sense to pass CC, CFLAGS, and >> similar properly into the tools Makefile. >> >> NOTE: in order to do this properly, we need to add some new >> definitions of HOSTAS and HOSTLD into the main kernel Makefile. If we >> don't do this and someone overrides "AS" or "LD" on the command line >> then those (which were intended for the target) will be used to build >> host side tools. We also make up some imaginary "HOSTASFLAGS" and >> "HOSTLDFLAGS". Someone could specify these, but if they don't at >> least these blank variables will properly clobber ASFLAGS and LDFLAGS >> from the kernel. >> >> This was discovered in the Chrome OS build system where CFLAGS (an >> environment variable) was accidentally left pointing to flags that >> would be an appropriate match to CC. The kernel didn't use these >> CFLAGS so it was never an issue. Turning on STACKVALIDATION, however, >> suddenly invoked a tools build that blew up. >> >> Signed-off-by: Douglas Anderson <dianders@chromium.org> >> --- >> >> Makefile | 30 ++++++++++++++++++++++++++++-- >> 1 file changed, 28 insertions(+), 2 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index cf007a31d575..0d3af0677d88 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -298,7 +298,9 @@ HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS) >> HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS) >> HOST_LFS_LIBS := $(shell getconf LFS_LIBS) >> >> +HOSTAS = as >> HOSTCC = gcc >> +HOSTLD = ld >> HOSTCXX = g++ >> HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ >> -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) >> @@ -1616,11 +1618,35 @@ image_name: >> # Clear a bunch of variables before executing the submake >> tools/: FORCE >> $(Q)mkdir -p $(objtree)/tools >> - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ >> + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ >> + LDFLAGS="$(HOSTLDFLAGS)" \ >> + CFLAGS="$(HOSTCFLAGS)" \ >> + CXXFLAGS="$(HOSTCXXFLAGS)" \ >> + $(MAKE) \ >> + AS="$(HOSTAS)" \ >> + CC="$(HOSTCC)" \ >> + CXX="$(HOSTCXX)" \ >> + LD="$(HOSTLD)" \ >> + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ >> + O=$(abspath $(objtree)) \ >> + subdir=tools \ >> + -C $(src)/tools/ >> >> tools/%: FORCE >> $(Q)mkdir -p $(objtree)/tools >> - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ $* >> + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ >> + LDFLAGS="$(HOSTLDFLAGS)" \ >> + CFLAGS="$(HOSTCFLAGS)" \ >> + CXXFLAGS="$(HOSTCXXFLAGS)" \ >> + $(MAKE) \ >> + AS="$(HOSTAS)" \ >> + CC="$(HOSTCC)" \ >> + CXX="$(HOSTCXX)" \ >> + LD="$(HOSTLD)" \ >> + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ >> + O=$(abspath $(objtree)) \ >> + subdir=tools \ >> + -C $(src)/tools/ $* >> > > Please do not do this. > > > > CC: for building tools that run on the target machine > HOSTCC: for building tools that run on the build machine > > > IMHO, this should be consistent to avoid confusion. > > > Grepping CROSS_COMPILE under tools/ directory, > I see many Makefile expect CC for the target system. > > For ex, tools/croup/Makefile > > CC = $(CROSS_COMPILE)gcc > > > > Why don't you fix tools/objtool/Makefile ? > > Interesting question. You are right, most tools are target tools, not host tools. Maybe it _would_ make sense to use HOSTCC/HOSTCFLAGS to build it. Copying Josh for input. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue, Oct 3, 2017 at 9:07 PM, Guenter Roeck <groeck@google.com> wrote: > On Tue, Oct 3, 2017 at 8:20 PM, Masahiro Yamada >> CC: for building tools that run on the target machine >> HOSTCC: for building tools that run on the build machine >> >> >> IMHO, this should be consistent to avoid confusion. >> >> >> Grepping CROSS_COMPILE under tools/ directory, >> I see many Makefile expect CC for the target system. >> >> For ex, tools/croup/Makefile >> >> CC = $(CROSS_COMPILE)gcc >> >> >> >> Why don't you fix tools/objtool/Makefile ? >> >> > > Interesting question. You are right, most tools are target tools, not > host tools. Maybe it _would_ make sense to use HOSTCC/HOSTCFLAGS to > build it. Copying Josh for input. Ah, good point. I'm not terribly familiar with the things under tools, so when I saw "objtool" I assumed it was following a standard pattern for tools. I can submit a patch for objtool's Makefile. ...or, if it makes more sense, I can submit a patch to move "objtool" to the scripts directory. ...or I can butt out of it. :) Which would folks prefer? -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 04, 2017 at 09:09:51AM -0700, Doug Anderson wrote: > Hi, > > On Tue, Oct 3, 2017 at 9:07 PM, Guenter Roeck <groeck@google.com> wrote: > > On Tue, Oct 3, 2017 at 8:20 PM, Masahiro Yamada > >> CC: for building tools that run on the target machine > >> HOSTCC: for building tools that run on the build machine > >> > >> > >> IMHO, this should be consistent to avoid confusion. > >> > >> > >> Grepping CROSS_COMPILE under tools/ directory, > >> I see many Makefile expect CC for the target system. > >> > >> For ex, tools/croup/Makefile > >> > >> CC = $(CROSS_COMPILE)gcc > >> > >> > >> > >> Why don't you fix tools/objtool/Makefile ? > >> > >> > > > > Interesting question. You are right, most tools are target tools, not > > host tools. Maybe it _would_ make sense to use HOSTCC/HOSTCFLAGS to > > build it. Copying Josh for input. Yes, converting objtool to use HOSTCC/HOSTCFLAGS etc would be a good improvement. It has a dependency on libsubcmd, so tools/lib/subcmd/Makefile will also need to be changed (and be careful not to break perf in the process). > Ah, good point. I'm not terribly familiar with the things under > tools, so when I saw "objtool" I assumed it was following a standard > pattern for tools. > > I can submit a patch for objtool's Makefile. ...or, if it makes more > sense, I can submit a patch to move "objtool" to the scripts > directory. ...or I can butt out of it. :) Which would folks prefer? In some ways objtool would be a more natural fit in the scripts dir. However, we decided to put it in tools because it might be useful outside of the kernel and it's much easier to extract it from the kernel that way. Also, it has a shared dependency on libsubcmd with perf, which is also in tools.
diff --git a/Makefile b/Makefile index cf007a31d575..0d3af0677d88 100644 --- a/Makefile +++ b/Makefile @@ -298,7 +298,9 @@ HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS) HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS) HOST_LFS_LIBS := $(shell getconf LFS_LIBS) +HOSTAS = as HOSTCC = gcc +HOSTLD = ld HOSTCXX = g++ HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) @@ -1616,11 +1618,35 @@ image_name: # Clear a bunch of variables before executing the submake tools/: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ + LDFLAGS="$(HOSTLDFLAGS)" \ + CFLAGS="$(HOSTCFLAGS)" \ + CXXFLAGS="$(HOSTCXXFLAGS)" \ + $(MAKE) \ + AS="$(HOSTAS)" \ + CC="$(HOSTCC)" \ + CXX="$(HOSTCXX)" \ + LD="$(HOSTLD)" \ + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ + O=$(abspath $(objtree)) \ + subdir=tools \ + -C $(src)/tools/ tools/%: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(src)/tools/ $* + $(Q)ASFLAGS="$(HOSTASFLAGS)"\ + LDFLAGS="$(HOSTLDFLAGS)" \ + CFLAGS="$(HOSTCFLAGS)" \ + CXXFLAGS="$(HOSTCXXFLAGS)" \ + $(MAKE) \ + AS="$(HOSTAS)" \ + CC="$(HOSTCC)" \ + CXX="$(HOSTCXX)" \ + LD="$(HOSTLD)" \ + MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" \ + O=$(abspath $(objtree)) \ + subdir=tools \ + -C $(src)/tools/ $* # Single targets # ---------------------------------------------------------------------------
The main Linux Makefiles and the tools sub-Makefiles have different conventions for passing in CC / CFLAGS. Here's brief summary for the kernel: * CC: target C compiler (must be passed as an argument to make to override) * HOSTCC: host C compiler (must be passed as an argument to make to override) * CFLAGS: ignored (kernel manages its own CFLAGS) * KCFLAGS: extra cflags for the target (expected as an env var) * HOSTCFLAGS: host C compiler flags (not modifiable by the caller of make) Here's a brief summary for the tools: * CC: host C compiler (must be passed as an argument to make to override) * CFLAGS: base arguments for the host C compiler which are added to by sub builds (expected as an env var) When the main kernel Makefile calls into the tools Makefile, it should adapt things from its syntax to the tools Makefile syntax. If we don't do this, we have a few issues: * If someone wants to user another compiler (like clang, maybe) for hostcc then the tools will still be compiled with gcc. * If you happen to be building and you left ${CFLAGS} set to something random (maybe it matches ${CC}, the _target_ C compiler, not the _host_ C compiler) then this random value will be used to compile the tools. In any case, it seems like it makes sense to pass CC, CFLAGS, and similar properly into the tools Makefile. NOTE: in order to do this properly, we need to add some new definitions of HOSTAS and HOSTLD into the main kernel Makefile. If we don't do this and someone overrides "AS" or "LD" on the command line then those (which were intended for the target) will be used to build host side tools. We also make up some imaginary "HOSTASFLAGS" and "HOSTLDFLAGS". Someone could specify these, but if they don't at least these blank variables will properly clobber ASFLAGS and LDFLAGS from the kernel. This was discovered in the Chrome OS build system where CFLAGS (an environment variable) was accidentally left pointing to flags that would be an appropriate match to CC. The kernel didn't use these CFLAGS so it was never an issue. Turning on STACKVALIDATION, however, suddenly invoked a tools build that blew up. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- Makefile | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-)