[U-Boot] [WIP] tools/env: cleanup host build flags
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
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
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
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
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
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
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
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
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
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
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
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
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.
participants (7)
-
Daniel Hobi -
Detlev Zundel -
Grant Edwards -
Mike Frysinger -
Scott Wood -
Steve Sakoman -
Wolfgang Denk