[U-Boot] [WIP] tools/env: cleanup host build flags

[U-Boot] [WIP] tools/env: cleanup host build flags

[Daniel Hobi]

This patch makes tools/env/Makefile more similar to tools/imls:
- define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
- include U-Boot headers using -idirafter to prevent picking up
  u-boot/include/errno.h.
- use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).
- use the cross compiler again (fw_printenv is intended for a
  hosted environment on the target).

Signed-off-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Wolfgang Denk <wd@denx.de>

---
 tools/env/Makefile |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)


Hi Scott,

In commit d984fed0 (makefiles: fixes for building build tools),
you suggest that using $(CC) with host flags (HOSTCFLAGS, etc)
is the correct way to use the cross compiler to generate binaries
for a hosted environment on the target.

On the other hand, you use $(HOSTCC) to generate the .depend file
in rules.mk which leads to wrong dependencies.

I think we need to differentiate three cases:
 - (free-standing) U-Boot: use CC and CFLAGS
 - native tools (mkimage, etc): use HOSTCC and HOSTCFLAGS
 - Linux environment on the target (imls, fw_printenv):

   Can we use CC and HOSTCFLAGS, or do we need a third set of
   variables for flags?

   If reusing HOSTCFLAGS: how do we fix dependency generation?

Best regards,
Daniel

diff --git a/tools/env/Makefile b/tools/env/Makefile
index f893040..a7bed87 100644
--- a/tools/env/Makefile
+++ b/tools/env/Makefile
@@ -23,19 +23,24 @@
 
 include $(TOPDIR)/config.mk
 
-SRCS	:= $(obj)crc32.c  fw_env.c  fw_env_main.c
+HOSTSRCS := $(obj)crc32.c  fw_env.c  fw_env_main.c
 HEADERS	:= fw_env.h
 
-HOSTCFLAGS += -Wall -DUSE_HOSTCC -I$(SRCTREE)/include
+# Compile for a hosted environment on the target
+HOSTCPPFLAGS  = -idirafter $(SRCTREE)/include \
+                -idirafter $(OBJTREE)/include2 \
+                -idirafter $(OBJTREE)/include \
+                -DUSE_HOSTCC
 
 ifeq ($(MTD_VERSION),old)
-HOSTCFLAGS += -DMTD_OLD
+HOSTCPPFLAGS += -DMTD_OLD
 endif
 
 all:	$(obj)fw_printenv
 
-$(obj)fw_printenv:	$(SRCS) $(HEADERS)
-	$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $(SRCS)
+# Some files complain if compiled with -pedantic, use HOSTCFLAGS_NOPED
+$(obj)fw_printenv:	$(HOSTSRCS) $(HEADERS)
+	$(CC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS)
 
 clean:
 	rm -f $(obj)fw_printenv $(obj)crc32.c
-- 
1.7.2.3

[U-Boot] [WIP] tools/env: cleanup host build flags

[Scott Wood]

On Mon, 11 Oct 2010 18:06:46 +0200
Daniel Hobi <daniel.hobi@schmid-telecom.ch> wrote:

> Hi Scott,
> 
> In commit d984fed0 (makefiles: fixes for building build tools),
> you suggest that using $(CC) with host flags (HOSTCFLAGS, etc)
> is the correct way to use the cross compiler to generate binaries
> for a hosted environment on the target.
> 
> On the other hand, you use $(HOSTCC) to generate the .depend file
> in rules.mk which leads to wrong dependencies.
> 
> I think we need to differentiate three cases:
>  - (free-standing) U-Boot: use CC and CFLAGS
>  - native tools (mkimage, etc): use HOSTCC and HOSTCFLAGS
>  - Linux environment on the target (imls, fw_printenv):
> 
>    Can we use CC and HOSTCFLAGS, or do we need a third set of
>    variables for flags?
> 
>    If reusing HOSTCFLAGS: how do we fix dependency generation?

I don't know if a separate set of flags is needed, but we probably want
separate OBJS/SRCS lists.  The dependencies are going to be different
based on which toolchain you use, even if the flags are the same.

-Scott

[U-Boot] [WIP] tools/env: cleanup host build flags

[Detlev Zundel]

Hello Daniel,

> This patch makes tools/env/Makefile more similar to tools/imls:
> - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
> - include U-Boot headers using -idirafter to prevent picking up
>   u-boot/include/errno.h.
> - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).
> - use the cross compiler again (fw_printenv is intended for a
>   hosted environment on the target).
>
> Signed-off-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
> Cc: Mike Frysinger <vapier@gentoo.org>
> Cc: Wolfgang Denk <wd@denx.de>

As this indeed fixes the cross-compilation problem:

Tested-by: Detlev Zundel <dzu@denx.de>

>  tools/env/Makefile |   15 ++++++++++-----
>  1 files changed, 10 insertions(+), 5 deletions(-)
>
>
> Hi Scott,
>
> In commit d984fed0 (makefiles: fixes for building build tools),
> you suggest that using $(CC) with host flags (HOSTCFLAGS, etc)
> is the correct way to use the cross compiler to generate binaries
> for a hosted environment on the target.
>
> On the other hand, you use $(HOSTCC) to generate the .depend file
> in rules.mk which leads to wrong dependencies.
>
> I think we need to differentiate three cases:
>  - (free-standing) U-Boot: use CC and CFLAGS
>  - native tools (mkimage, etc): use HOSTCC and HOSTCFLAGS
>  - Linux environment on the target (imls, fw_printenv):
>
>    Can we use CC and HOSTCFLAGS, or do we need a third set of
>    variables for flags?
>
>    If reusing HOSTCFLAGS: how do we fix dependency generation?

I also don't know, but this fixes a bug, so I want the patch in ;)

Cheers
  Detlev

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [WIP] tools/env: cleanup host build flags

[Steve Sakoman]

On Tue, Nov 9, 2010 at 7:03 AM, Detlev Zundel <dzu@denx.de> wrote:
> Hello Daniel,
>
>> This patch makes tools/env/Makefile more similar to tools/imls:
>> - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
>> - include U-Boot headers using -idirafter to prevent picking up
>> ? u-boot/include/errno.h.
>> - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).
>> - use the cross compiler again (fw_printenv is intended for a
>> ? hosted environment on the target).
>>
>> Signed-off-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
>> Cc: Mike Frysinger <vapier@gentoo.org>
>> Cc: Wolfgang Denk <wd@denx.de>
>
> As this indeed fixes the cross-compilation problem:
>
> Tested-by: Detlev Zundel <dzu@denx.de>

Agreed!

Tested-by: Steve Sakoman <steve.sakoman@linaro.org>

[U-Boot] [WIP] tools/env: cleanup host build flags

[Mike Frysinger]

On Monday, October 11, 2010 12:06:46 Daniel Hobi wrote:
> This patch makes tools/env/Makefile more similar to tools/imls:
> - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
> - include U-Boot headers using -idirafter to prevent picking up
>   u-boot/include/errno.h.

these things really need to be unified instead of copying & pasting them from 
other Makefiles

> - use the cross compiler again (fw_printenv is intended for a
>   hosted environment on the target).

the cross-compiler used to create u-boot has no guarantee that it'll produce 
executables useful for the target OS.  often this isnt the case.  HOSTCC 
however will produce useful userspace applications for whatever host the user 
has selection.

this works perfectly fine for me:
	make tools env HOSTCC=bfin-uclinux-gcc
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101110/66045816/attachment.pgp 

[U-Boot] [WIP] tools/env: cleanup host build flags

[Daniel Hobi]

Hi Mike,

On 10.11.2010 10:23, Mike Frysinger wrote:
> On Monday, October 11, 2010 12:06:46 Daniel Hobi wrote:
>> - use the cross compiler again (fw_printenv is intended for a
>>   hosted environment on the target).
> 
> the cross-compiler used to create u-boot has no guarantee that it'll produce 
> executables useful for the target OS.  often this isnt the case.  HOSTCC 
> however will produce useful userspace applications for whatever host the user 
> has selection.

But in many cases the default for CC is sufficient to build such
executables, whereas the default for HOSTCC is almost never (except when
HOST==TARGET).

Usually HOSTCC refers to the system where the toolchain is running. So
maybe we should introduce TARGETCC to build executables running on the
system the toolchain is generating executables for. TARGETCC would
default to CC and could be overriden in the way you demonstrated:

> this works perfectly fine for me:
> 	make tools env HOSTCC=bfin-uclinux-gcc

Best regards,
Daniel

[U-Boot] [WIP] tools/env: cleanup host build flags

[Mike Frysinger]

On Wednesday, November 10, 2010 06:58:51 Daniel Hobi wrote:
> On 10.11.2010 10:23, Mike Frysinger wrote:
> > On Monday, October 11, 2010 12:06:46 Daniel Hobi wrote:
> >> - use the cross compiler again (fw_printenv is intended for a
> >> 
> >>   hosted environment on the target).
> > 
> > the cross-compiler used to create u-boot has no guarantee that it'll
> > produce executables useful for the target OS.  often this isnt the case.
> >  HOSTCC however will produce useful userspace applications for whatever
> > host the user has selection.
> 
> But in many cases the default for CC is sufficient to build such
> executables, whereas the default for HOSTCC is almost never (except when
> HOST==TARGET).

the difference is that the current state is consistent across all tools.  i 
wish to cross-compile all of them for different systems and not just subsets 
in different inconsistent ways.

> Usually HOSTCC refers to the system where the toolchain is running. So
> maybe we should introduce TARGETCC to build executables running on the
> system the toolchain is generating executables for. TARGETCC would

i'm ok with splitting the logic a bit more to refine the intentions
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101110/4f089a9c/attachment.pgp 

[U-Boot] [PATCH] tools/env: cleanup host build flags

[Daniel Hobi]

This patch makes tools/env/Makefile more similar to tools/imls:
- define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
- include U-Boot headers using -idirafter to prevent picking up
  u-boot/include/errno.h.
- use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).

In order to cross-compile tools/env, override the HOSTCC variable
as in this example:

  make tools env HOSTCC=bfin-uclinux-gcc

Signed-off-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
---
 tools/env/Makefile |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

Let's fix these issues now and cleanup the CC vs HOSTCC discrepancy
later.

diff --git a/tools/env/Makefile b/tools/env/Makefile
index f893040..04dfe9c 100644
--- a/tools/env/Makefile
+++ b/tools/env/Makefile
@@ -23,19 +23,24 @@
 
 include $(TOPDIR)/config.mk
 
-SRCS	:= $(obj)crc32.c  fw_env.c  fw_env_main.c
+HOSTSRCS := $(obj)crc32.c  fw_env.c  fw_env_main.c
 HEADERS	:= fw_env.h
 
-HOSTCFLAGS += -Wall -DUSE_HOSTCC -I$(SRCTREE)/include
+# Compile for a hosted environment on the target
+HOSTCPPFLAGS  = -idirafter $(SRCTREE)/include \
+                -idirafter $(OBJTREE)/include2 \
+                -idirafter $(OBJTREE)/include \
+                -DUSE_HOSTCC
 
 ifeq ($(MTD_VERSION),old)
-HOSTCFLAGS += -DMTD_OLD
+HOSTCPPFLAGS += -DMTD_OLD
 endif
 
 all:	$(obj)fw_printenv
 
-$(obj)fw_printenv:	$(SRCS) $(HEADERS)
-	$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $(SRCS)
+# Some files complain if compiled with -pedantic, use HOSTCFLAGS_NOPED
+$(obj)fw_printenv:	$(HOSTSRCS) $(HEADERS)
+	$(HOSTCC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS)
 
 clean:
 	rm -f $(obj)fw_printenv $(obj)crc32.c
-- 
1.7.3.2

[U-Boot] [WIP] tools/env: cleanup host build flags

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201011100423.13449.vapier@gentoo.org> you wrote:
>
> > - use the cross compiler again (fw_printenv is intended for a
> >   hosted environment on the target).
> 
> the cross-compiler used to create u-boot has no guarantee that it'll produce 
> executables useful for the target OS.  often this isnt the case.  HOSTCC 

Really? You mean, you need different tool chains to build U-Boot, the
Linux kernel or user space applications?  Frankly, I consider those
tool chains broken. 

> however will produce useful userspace applications for whatever host the user 
> has selection.


This makes no sense to me.  We have CROSS_COMPILE set, and that is
supposed to be used for cross compilation.

IIRC, HOSTCC refers to the C compiler on the and for the build host,
i. e. when running on a x86 system it will create x86 code.  This is
obviously wrong when we try to build fw_printenv for, say, a PPC4xx
system.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"A witty saying proves nothing."                           - Voltaire

[U-Boot] [WIP] tools/env: cleanup host build flags

[Mike Frysinger]

On Wednesday, November 10, 2010 15:00:48 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > - use the cross compiler again (fw_printenv is intended for a
> > > 
> > >   hosted environment on the target).
> > 
> > the cross-compiler used to create u-boot has no guarantee that it'll
> > produce executables useful for the target OS.  often this isnt the case.
> >  HOSTCC
> 
> Really? You mean, you need different tool chains to build U-Boot, the
> Linux kernel or user space applications?  Frankly, I consider those
> tool chains broken.

based on your based comments, i'm really not surprised.  you constantly prefer 
to ignore reality and the state of GNU toolchains.  plus, you ignore other 
obvious setups.  just because the toolchain in question may produce binaries 
doesnt mean the binaries are in the ABI format desired for linux userspace.

blindly assuming the toolchain that is being used to create u-boot will also 
be used for creating userspace apps is fundamentally wrong.

> > however will produce useful userspace applications for whatever host the
> > user has selection.
> 
> This makes no sense to me.  We have CROSS_COMPILE set, and that is
> supposed to be used for cross compilation.
> 
> IIRC, HOSTCC refers to the C compiler on the and for the build host,
> i. e. when running on a x86 system it will create x86 code.  This is
> obviously wrong when we try to build fw_printenv for, say, a PPC4xx
> system.

and it is trivial for the user to say "i wish to build tools for PPC4xx 
userland"
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101110/1714b822/attachment.pgp 

[U-Boot] [WIP] tools/env: cleanup host build flags

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201011101706.17988.vapier@gentoo.org> you wrote:
>
> based on your based comments, i'm really not surprised.  you constantly prefer 
> to ignore reality and the state of GNU toolchains.  plus, you ignore other

I'm a software developer.  If tool chains are broken, I try to fix them
or get them fixed.  My time is way to precious to be wasted on broken
tools.  Rather I spend it on getting tools to do what I need.

> obvious setups.  just because the toolchain in question may produce binaries 
> doesnt mean the binaries are in the ABI format desired for linux userspace.
>
> blindly assuming the toolchain that is being used to create u-boot will also 
> be used for creating userspace apps is fundamentally wrong.

Sincere condolences if you have to work in such an environment.

But even then, this is not a reason to break the code for people who
are in a more lucky position.

> > IIRC, HOSTCC refers to the C compiler on the and for the build host,
> > i. e. when running on a x86 system it will create x86 code.  This is
> > obviously wrong when we try to build fw_printenv for, say, a PPC4xx
> > system.
>
> and it is trivial for the user to say "i wish to build tools for PPC4xx 
> userland"

Is it? And how so?  And why would this not be the default setting,
then?


Mike, please state clearly if you have a solution for the current
problem, or I will just revert that commit.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cleverness and Style have no place in getting a project completed.
                                                  -- Tom Christiansen

[U-Boot] [WIP] tools/env: cleanup host build flags

[Mike Frysinger]

On Wednesday, November 10, 2010 17:25:31 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > IIRC, HOSTCC refers to the C compiler on the and for the build host,
> > > i. e. when running on a x86 system it will create x86 code.  This is
> > > obviously wrong when we try to build fw_printenv for, say, a PPC4xx
> > > system.
> > 
> > and it is trivial for the user to say "i wish to build tools for PPC4xx
> > userland"
> 
> Is it? And how so?

i already said multiple times how to do it:
	make tools env HOSTCC=bfin-uclinux-gcc

and that works for *all* tools instead of just some

> And why would this not be the default setting, then?

i already said why it doesnt make sense to assume "one toolchain fits all" and 
why that requirement is fundamentally wrong.  Daniel already suggested a 
refinement to better control intentions which isnt fundamentally broken.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101110/ebc8b37d/attachment.pgp 

[U-Boot] [WIP] tools/env: cleanup host build flags

[Grant Edwards]

On 2010-11-10, Wolfgang Denk <wd@denx.de> wrote:
> Dear Mike Frysinger,
>
> In message <201011100423.13449.vapier@gentoo.org> you wrote:
>>
>> > - use the cross compiler again (fw_printenv is intended for a
>> >   hosted environment on the target).
>> 
>> the cross-compiler used to create u-boot has no guarantee that it'll produce 
>> executables useful for the target OS.  often this isnt the case.  HOSTCC 
>
> Really? You mean, you need different tool chains to build U-Boot, the
> Linux kernel or user space applications?  Frankly, I consider those
> tool chains broken. 

Sounds like somethings broken to me as well. I've always used the same
toolchain for U-Boot, Kernel, Atmel bootstrap, and user-space stuff
(vis buildroot).

The only think I use a separate toolchain for are Atmel's "applets"
that are part of the SAM-BA utility -- and that's only because I'm too
lazy to fix Atmel's Makefiles so they call the compiler with the
proper flags.

-- 
Grant Edwards               grant.b.edwards        Yow! Are we THERE yet?
                                  at               
                              gmail.com