This fixes cross compilation of libapi.
Signed-off-by: Lucas Stach <[email protected]>
---
tools/lib/api/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
index d85904dc9b38..9383bb866664 100644
--- a/tools/lib/api/Makefile
+++ b/tools/lib/api/Makefile
@@ -10,6 +10,7 @@ endif
CC = $(CROSS_COMPILE)gcc
AR = $(CROSS_COMPILE)ar
+LD = $(CROSS_COMPILE)ld
MAKEFLAGS += --no-print-directory
--
2.7.0
Em Thu, Mar 17, 2016 at 06:27:50PM +0100, Lucas Stach escreveu:
> This fixes cross compilation of libapi.
Humm, I guess that tools/lib/subcmd/Makefile has the same problem? And
there are also other cases where LD is not being set with CROSS_COMPILE,
Jiri, is there something else at play here?
/me needs to cross compile all this code...
- Arnaldo
> Signed-off-by: Lucas Stach <[email protected]>
> ---
> tools/lib/api/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
> index d85904dc9b38..9383bb866664 100644
> --- a/tools/lib/api/Makefile
> +++ b/tools/lib/api/Makefile
> @@ -10,6 +10,7 @@ endif
>
> CC = $(CROSS_COMPILE)gcc
> AR = $(CROSS_COMPILE)ar
> +LD = $(CROSS_COMPILE)ld
>
> MAKEFLAGS += --no-print-directory
>
> --
> 2.7.0
On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 17, 2016 at 06:27:50PM +0100, Lucas Stach escreveu:
> > This fixes cross compilation of libapi.
>
> Humm, I guess that tools/lib/subcmd/Makefile has the same problem? And
> there are also other cases where LD is not being set with CROSS_COMPILE,
> Jiri, is there something else at play here?
>
> /me needs to cross compile all this code...
Yeah, I already fixed the libsubcmd issue with commit c1d45c3abd49 in
tip/core/objtool. (Sorry, I probably should have CC'ed you and Jiri.)
>
> - Arnaldo
>
> > Signed-off-by: Lucas Stach <[email protected]>
> > ---
> > tools/lib/api/Makefile | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
> > index d85904dc9b38..9383bb866664 100644
> > --- a/tools/lib/api/Makefile
> > +++ b/tools/lib/api/Makefile
> > @@ -10,6 +10,7 @@ endif
> >
> > CC = $(CROSS_COMPILE)gcc
> > AR = $(CROSS_COMPILE)ar
> > +LD = $(CROSS_COMPILE)ld
> >
> > MAKEFLAGS += --no-print-directory
> >
> > --
> > 2.7.0
--
Josh
On Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf wrote:
> On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Mar 17, 2016 at 06:27:50PM +0100, Lucas Stach escreveu:
> > > This fixes cross compilation of libapi.
> >
> > Humm, I guess that tools/lib/subcmd/Makefile has the same problem? And
> > there are also other cases where LD is not being set with CROSS_COMPILE,
> > Jiri, is there something else at play here?
> >
> > /me needs to cross compile all this code...
>
> Yeah, I already fixed the libsubcmd issue with commit c1d45c3abd49 in
> tip/core/objtool. (Sorry, I probably should have CC'ed you and Jiri.)
Hm, I wonder why the 0-day kbuild bot didn't catch this issue before,
since I know it does some cross-compiling. Does it not build perf?
--
Josh
Em Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf escreveu:
> On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Mar 17, 2016 at 06:27:50PM +0100, Lucas Stach escreveu:
> > > This fixes cross compilation of libapi.
> >
> > Humm, I guess that tools/lib/subcmd/Makefile has the same problem? And
> > there are also other cases where LD is not being set with CROSS_COMPILE,
> > Jiri, is there something else at play here?
> >
> > /me needs to cross compile all this code...
>
> Yeah, I already fixed the libsubcmd issue with commit c1d45c3abd49 in
> tip/core/objtool. (Sorry, I probably should have CC'ed you and Jiri.)
Not a problem, it will all get merged eventually, but I noticed this:
-CC = $(CROSS_COMPILE)gcc
-AR = $(CROSS_COMPILE)ar
+CC ?= $(CROSS_COMPILE)gcc
+LD ?= $(CROSS_COMPILE)ld
+AR ?= $(CROSS_COMPILE)ar
This is how you fixed it, which is different from what other places do
for cross compiling, for instance, this is how tools/lib/bpf/Makefile
does (and it isn't setting LD as well):
# Allow setting CC and AR, or setting CROSS_COMPILE as a prefix.
$(call allow-override,CC,$(CROSS_COMPILE)gcc)
$(call allow-override,AR,$(CROSS_COMPILE)ar)
Which is different from what the kernel does in its main Makefile:
# Make variables (CC, etc...)
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
CC = $(CROSS_COMPILE)gcc
I wonder if we could settle in one of these styles or if there is really
a reason to be creative :-)
Better, all this could go to tools/scripts/Makefile.include?
- Arnaldo
> > > Signed-off-by: Lucas Stach <[email protected]>
> > > ---
> > > tools/lib/api/Makefile | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
> > > index d85904dc9b38..9383bb866664 100644
> > > --- a/tools/lib/api/Makefile
> > > +++ b/tools/lib/api/Makefile
> > > @@ -10,6 +10,7 @@ endif
> > >
> > > CC = $(CROSS_COMPILE)gcc
> > > AR = $(CROSS_COMPILE)ar
> > > +LD = $(CROSS_COMPILE)ld
> > >
> > > MAKEFLAGS += --no-print-directory
> > >
> > > --
> > > 2.7.0
>
> --
> Josh
On Fri, Mar 18, 2016 at 01:45:22PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf escreveu:
> > On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Mar 17, 2016 at 06:27:50PM +0100, Lucas Stach escreveu:
> > > > This fixes cross compilation of libapi.
> > >
> > > Humm, I guess that tools/lib/subcmd/Makefile has the same problem? And
> > > there are also other cases where LD is not being set with CROSS_COMPILE,
> > > Jiri, is there something else at play here?
> > >
> > > /me needs to cross compile all this code...
> >
> > Yeah, I already fixed the libsubcmd issue with commit c1d45c3abd49 in
> > tip/core/objtool. (Sorry, I probably should have CC'ed you and Jiri.)
>
> Not a problem, it will all get merged eventually, but I noticed this:
>
> -CC = $(CROSS_COMPILE)gcc
> -AR = $(CROSS_COMPILE)ar
> +CC ?= $(CROSS_COMPILE)gcc
> +LD ?= $(CROSS_COMPILE)ld
> +AR ?= $(CROSS_COMPILE)ar
>
> This is how you fixed it, which is different from what other places do
> for cross compiling, for instance, this is how tools/lib/bpf/Makefile
> does (and it isn't setting LD as well):
>
> # Allow setting CC and AR, or setting CROSS_COMPILE as a prefix.
> $(call allow-override,CC,$(CROSS_COMPILE)gcc)
> $(call allow-override,AR,$(CROSS_COMPILE)ar)
>
> Which is different from what the kernel does in its main Makefile:
>
> # Make variables (CC, etc...)
> AS = $(CROSS_COMPILE)as
> LD = $(CROSS_COMPILE)ld
> CC = $(CROSS_COMPILE)gcc
>
> I wonder if we could settle in one of these styles or if there is really
> a reason to be creative :-)
>
> Better, all this could go to tools/scripts/Makefile.include?
Yeah, I agree that it would be good to come up with a common and
consistent approach tools-wide if possible.
The reason I used '?=' is because objtool needs to be built with the
host compiler, and the tools kbuild doesn't have hostprogs and HOSTCC.
So I and overrode the CC variable. From tools/objtool/Makefile:
# always use the host compiler
CC = gcc
LD = ld
AR = ar
So the 'CC ?= $(CROSS_COMPILE)gcc' in tools/lib/subcmd/Makefile allows
the objtool Makefile to override the cross-compilation and use the host
compiler instead.
I _think_ 'allow-override' would also work, because the objtool Makefile
exports the CC/LD/AR variables to the environment before descending into
the subcmd directory. And 'allow-override' seems to allow overriding
those variables if they were set in the environment.
So 'allow-override' would probably be a good option.
--
Josh
Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
> On Fri, Mar 18, 2016 at 01:45:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf escreveu:
> > > On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > Which is different from what the kernel does in its main Makefile:
> > # Make variables (CC, etc...)
> > AS = $(CROSS_COMPILE)as
> > LD = $(CROSS_COMPILE)ld
> > CC = $(CROSS_COMPILE)gcc
> > I wonder if we could settle in one of these styles or if there is really
> > a reason to be creative :-)
> > Better, all this could go to tools/scripts/Makefile.include?
> Yeah, I agree that it would be good to come up with a common and
> consistent approach tools-wide if possible.
<SNOP>
> So 'allow-override' would probably be a good option.
Humm, my preference is to make tools/ look like the kernel, and the
kernel doesn't use that allow-override thing, right? So perhaps add what
is missing to make it look exactly like the kernel and then ditch this
allow-override thing?
What about having all this in a single place in tools/script/?
- Arnaldo
Em Fri, Mar 18, 2016 at 11:43:39AM -0500, Josh Poimboeuf escreveu:
> On Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf wrote:
> > On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Mar 17, 2016 at 06:27:50PM +0100, Lucas Stach escreveu:
> > > > This fixes cross compilation of libapi.
> > >
> > > Humm, I guess that tools/lib/subcmd/Makefile has the same problem? And
> > > there are also other cases where LD is not being set with CROSS_COMPILE,
> > > Jiri, is there something else at play here?
> > >
> > > /me needs to cross compile all this code...
> >
> > Yeah, I already fixed the libsubcmd issue with commit c1d45c3abd49 in
> > tip/core/objtool. (Sorry, I probably should have CC'ed you and Jiri.)
>
> Hm, I wonder why the 0-day kbuild bot didn't catch this issue before,
> since I know it does some cross-compiling. Does it not build perf?
Unfortunately I don't think so, IIRC there was some discussion, with
Jiri perhaps, about having it building perf, but I don't know how that
ended up.
- Arnaldo
On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Mar 18, 2016 at 01:45:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf escreveu:
> > > > On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Which is different from what the kernel does in its main Makefile:
>
> > > # Make variables (CC, etc...)
> > > AS = $(CROSS_COMPILE)as
> > > LD = $(CROSS_COMPILE)ld
> > > CC = $(CROSS_COMPILE)gcc
>
> > > I wonder if we could settle in one of these styles or if there is really
> > > a reason to be creative :-)
>
> > > Better, all this could go to tools/scripts/Makefile.include?
>
> > Yeah, I agree that it would be good to come up with a common and
> > consistent approach tools-wide if possible.
>
> <SNOP>
> > So 'allow-override' would probably be a good option.
>
> Humm, my preference is to make tools/ look like the kernel, and the
> kernel doesn't use that allow-override thing, right? So perhaps add what
> is missing to make it look exactly like the kernel and then ditch this
> allow-override thing?
To achieve that I think the 'hostprogs' stuff would also need to be
ported over. Not sure how much work that would be.
> What about having all this in a single place in tools/script/?
Having it in a single place sounds good to me.
--
Josh
On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Mar 18, 2016 at 01:45:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf escreveu:
> > > > On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Which is different from what the kernel does in its main Makefile:
>
> > > # Make variables (CC, etc...)
> > > AS = $(CROSS_COMPILE)as
> > > LD = $(CROSS_COMPILE)ld
> > > CC = $(CROSS_COMPILE)gcc
>
> > > I wonder if we could settle in one of these styles or if there is really
> > > a reason to be creative :-)
>
> > > Better, all this could go to tools/scripts/Makefile.include?
>
> > Yeah, I agree that it would be good to come up with a common and
> > consistent approach tools-wide if possible.
>
> <SNOP>
> > So 'allow-override' would probably be a good option.
>
> Humm, my preference is to make tools/ look like the kernel, and the
> kernel doesn't use that allow-override thing, right? So perhaps add what
> is missing to make it look exactly like the kernel and then ditch this
> allow-override thing?
Steven explained his reason for allow-override in the comment above it,
please make sure the new solution follows that
>
> What about having all this in a single place in tools/script/?
maybe tools/script/Makefile.comp
jirka
Em Mon, Mar 21, 2016 at 09:08:52AM +0100, Jiri Olsa escreveu:
> On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
> > > So 'allow-override' would probably be a good option.
> > Humm, my preference is to make tools/ look like the kernel, and the
> > kernel doesn't use that allow-override thing, right? So perhaps add what
> > is missing to make it look exactly like the kernel and then ditch this
> > allow-override thing?
> Steven explained his reason for allow-override in the comment above it,
> please make sure the new solution follows that
Sure, and I'm no make guru, but what puzzles me is why isn't this
required in:
[acme@jouet linux]$ grep -w ^CC Makefile
CC = $(CROSS_COMPILE)gcc
[acme@jouet linux]$
> > What about having all this in a single place in tools/script/?
>
> maybe tools/script/Makefile.comp
But then we would have to include multiple files in each Makefile,
perhaps it would be better to stash this in
tools/scripts/Makefile.include, that way we wouldn't have to include
any new file.
- Arnaldo
P.S.
While looking at the main kernel Makefile git history I found goodies we
could use in tools/, like:
commit 84336466011c589b6af554f2f2f1fcfa1a5c1437
Author: Roland McGrath <[email protected]>
Date: Mon Dec 21 16:24:06 2009 -0800
kconfig CROSS_COMPILE option
-------------------------------------------------------------------------
And also by trying hard to mimic (preferrably use a exact copy) the kernel we
can avoid suffering from subtle stuff like:
commit 2331d1a6cd3d6e580bc88b9a160066d9e1177fe1
Author: Sam Ravnborg <[email protected]>
Date: Sun Oct 11 23:22:58 2009 +0200
kbuild: revert "save ARCH & CROSS_COMPILE ..."
-------------------------------------------------------------------------
On Mon, Mar 21, 2016 at 05:40:30PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Mar 21, 2016 at 09:08:52AM +0100, Jiri Olsa escreveu:
> > On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
> > > > So 'allow-override' would probably be a good option.
>
> > > Humm, my preference is to make tools/ look like the kernel, and the
> > > kernel doesn't use that allow-override thing, right? So perhaps add what
> > > is missing to make it look exactly like the kernel and then ditch this
> > > allow-override thing?
>
> > Steven explained his reason for allow-override in the comment above it,
> > please make sure the new solution follows that
>
> Sure, and I'm no make guru, but what puzzles me is why isn't this
> required in:
>
> [acme@jouet linux]$ grep -w ^CC Makefile
> CC = $(CROSS_COMPILE)gcc
> [acme@jouet linux]$
Steve has special requirements I guess ;-) CC-ed
>
> > > What about having all this in a single place in tools/script/?
> >
> > maybe tools/script/Makefile.comp
>
> But then we would have to include multiple files in each Makefile,
> perhaps it would be better to stash this in
> tools/scripts/Makefile.include, that way we wouldn't have to include
> any new file.
sure, np
jirka
On Tue, 22 Mar 2016 08:10:10 +0100
Jiri Olsa <[email protected]> wrote:
> On Mon, Mar 21, 2016 at 05:40:30PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Mar 21, 2016 at 09:08:52AM +0100, Jiri Olsa escreveu:
> > > On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
> > > > > So 'allow-override' would probably be a good option.
> >
> > > > Humm, my preference is to make tools/ look like the kernel, and the
> > > > kernel doesn't use that allow-override thing, right? So perhaps add what
> > > > is missing to make it look exactly like the kernel and then ditch this
> > > > allow-override thing?
> >
> > > Steven explained his reason for allow-override in the comment above it,
> > > please make sure the new solution follows that
> >
> > Sure, and I'm no make guru, but what puzzles me is why isn't this
> > required in:
> >
> > [acme@jouet linux]$ grep -w ^CC Makefile
> > CC = $(CROSS_COMPILE)gcc
> > [acme@jouet linux]$
>
> Steve has special requirements I guess ;-) CC-ed
>
I just copied what I had in trace-cmd. David Sharp is the one that
added that code.
Link: http://lkml.kernel.org/r/[email protected]
-- Steve
Em Tue, Mar 22, 2016 at 08:50:42AM -0400, Steven Rostedt escreveu:
> On Tue, 22 Mar 2016 08:10:10 +0100
> Jiri Olsa <[email protected]> wrote:
>
> > On Mon, Mar 21, 2016 at 05:40:30PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Mar 21, 2016 at 09:08:52AM +0100, Jiri Olsa escreveu:
> > > > On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
> > > > > > So 'allow-override' would probably be a good option.
> > >
> > > > > Humm, my preference is to make tools/ look like the kernel, and the
> > > > > kernel doesn't use that allow-override thing, right? So perhaps add what
> > > > > is missing to make it look exactly like the kernel and then ditch this
> > > > > allow-override thing?
> > >
> > > > Steven explained his reason for allow-override in the comment above it,
> > > > please make sure the new solution follows that
> > >
> > > Sure, and I'm no make guru, but what puzzles me is why isn't this
> > > required in:
> > >
> > > [acme@jouet linux]$ grep -w ^CC Makefile
> > > CC = $(CROSS_COMPILE)gcc
> > > [acme@jouet linux]$
> >
> > Steve has special requirements I guess ;-) CC-ed
> >
>
> I just copied what I had in trace-cmd. David Sharp is the one that
> added that code.
>
> Link: http://lkml.kernel.org/r/[email protected]
David, so, what was the usecase for that? Something we can try to
reproduce so that we can check if the kernel solution covers your
specific case?
- Arnaldo
On Tue, Mar 22, 2016 at 7:42 AM, Arnaldo Carvalho de Melo
<[email protected]> wrote:
> Em Tue, Mar 22, 2016 at 08:50:42AM -0400, Steven Rostedt escreveu:
>> On Tue, 22 Mar 2016 08:10:10 +0100
>> Jiri Olsa <[email protected]> wrote:
>>
>> > On Mon, Mar 21, 2016 at 05:40:30PM -0300, Arnaldo Carvalho de Melo wrote:
>> > > Em Mon, Mar 21, 2016 at 09:08:52AM +0100, Jiri Olsa escreveu:
>> > > > On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
>> > > > > Em Fri, Mar 18, 2016 at 12:16:23PM -0500, Josh Poimboeuf escreveu:
>> > > > > > So 'allow-override' would probably be a good option.
>> > >
>> > > > > Humm, my preference is to make tools/ look like the kernel, and the
>> > > > > kernel doesn't use that allow-override thing, right? So perhaps add what
>> > > > > is missing to make it look exactly like the kernel and then ditch this
>> > > > > allow-override thing?
>> > >
>> > > > Steven explained his reason for allow-override in the comment above it,
>> > > > please make sure the new solution follows that
>> > >
>> > > Sure, and I'm no make guru, but what puzzles me is why isn't this
>> > > required in:
>> > >
>> > > [acme@jouet linux]$ grep -w ^CC Makefile
>> > > CC = $(CROSS_COMPILE)gcc
This works, but doesn't allow setting CC from env since it is
unconditionally overwritten here.
>> > > [acme@jouet linux]$
>> >
>> > Steve has special requirements I guess ;-) CC-ed
>> >
>>
>> I just copied what I had in trace-cmd. David Sharp is the one that
>> added that code.
>>
>> Link: http://lkml.kernel.org/r/[email protected]
>
> David, so, what was the usecase for that? Something we can try to
> reproduce so that we can check if the kernel solution covers your
> specific case?
>
> - Arnaldo
It was a very long time ago, so I don't fully remember my specific
requirements at the time.
However, I'm sure I was wanting to set just "CROSS_COMPILE" from the
environment rather than all of CC, LD, AS, AR, etc, while still
allowing the flexibility to set CC, etc from the environment.
If you have just:
CC ?= $(CROSS_COMPILE)gcc
well, that line will never have any effect (not even the value of
"gcc"), because CC is already set by default by make itself (to "cc").
Demo (gmail won't let me paste tabs, so you'll have to fix the tabs in
the "all" rule):
"""
$ cat Makefile
define allow-override
$(if $(or $(findstring environment,$(origin $(1))),\
$(findstring command line,$(origin $(1)))),,\
$(eval $(1) = $(2)))
endef
CC ?= $(CROSS_COMPILE)gcc
$(call allow-override,cross_CC,$(CROSS_COMPILE)gcc)
all:
@echo "CC: $(CC)"
@echo "cross_CC: $(cross_CC)"
$ make -f Makefile
CC: cc
cross_CC: gcc
$ CC=other-gcc cross_CC=other-gcc make -f Makefile
CC: other-gcc
cross_CC: other-gcc
$ CROSS_COMPILE=cross- make -f Makefile
CC: cc
cross_CC: cross-gcc
"""
So, note that without allow-override:
- The set default of "gcc" is not respected.
- Setting CC from the env does work.
- Setting CROSS_COMPILE from the env is not effective.
Hence the title of the patch and macro: "Makefiles suck". ;)
BTW: s/env/command line/ is true as well, i.e. running: `make
CROSS_COMPILE=cross-`
On Tue, Mar 22, 2016 at 11:22 AM, David Sharp <[email protected]> wrote:
> So, note that without allow-override:
> - The set default of "gcc" is not respected.
> - Setting CC from the env does work.
> - Setting CROSS_COMPILE from the env is not effective.