[U-Boot] [PATCH] fdt: Ensure that libfdt_env.h comes from U-Boot
When building host utilities, we include libfdt.h from the host, not from U-Boot. This in turn brings in libfdt_env.h from the host, which can mess up the types and cause a build failure, depending on the host environment. To fix this, force inclusion of U-Boot's libfdt_env.h so that the types are correct.
Another way to fix this is to use -nostdinc and -idirafter to ensure that system includes are included after U-Boot ones. Unfortunately this means that U-Boot's errno.h gets included instead of the system one. This in turn requires a hack to errno.h to redirect things, so all in all the solution in this patch is probably cleaner.
Signed-off-by: Simon Glass sjg@chromium.org --- tools/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/Makefile b/tools/Makefile index c5952fc..889c897 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -164,7 +164,8 @@ NOPEDOBJS := $(addprefix $(obj),$(NOPED_OBJ_FILES-y)) # Use native tools and options # Define __KERNEL_STRICT_NAMES to prevent typedef overlaps # -HOSTCPPFLAGS = -idirafter $(SRCTREE)/include \ +HOSTCPPFLAGS = -include $(SRCTREE)/include/libfdt_env.h \ + -idirafter $(SRCTREE)/include \ -idirafter $(OBJTREE)/include2 \ -idirafter $(OBJTREE)/include \ -I $(SRCTREE)/lib/libfdt \
Hi Tom / Jerry,
On Mon, Mar 11, 2013 at 9:30 AM, Simon Glass sjg@chromium.org wrote:
When building host utilities, we include libfdt.h from the host, not from U-Boot. This in turn brings in libfdt_env.h from the host, which can mess up the types and cause a build failure, depending on the host environment. To fix this, force inclusion of U-Boot's libfdt_env.h so that the types are correct.
Another way to fix this is to use -nostdinc and -idirafter to ensure that system includes are included after U-Boot ones. Unfortunately this means that U-Boot's errno.h gets included instead of the system one. This in turn requires a hack to errno.h to redirect things, so all in all the solution in this patch is probably cleaner.
Signed-off-by: Simon Glass sjg@chromium.org
tools/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/Makefile b/tools/Makefile index c5952fc..889c897 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -164,7 +164,8 @@ NOPEDOBJS := $(addprefix $(obj),$(NOPED_OBJ_FILES-y)) # Use native tools and options # Define __KERNEL_STRICT_NAMES to prevent typedef overlaps # -HOSTCPPFLAGS = -idirafter $(SRCTREE)/include \ +HOSTCPPFLAGS = -include $(SRCTREE)/include/libfdt_env.h \
-idirafter $(SRCTREE)/include \ -idirafter $(OBJTREE)/include2 \ -idirafter $(OBJTREE)/include \ -I $(SRCTREE)/lib/libfdt \-- 1.8.1.3
This is a very late patch, and I'm not 100% sure this is the best way to fix it. But with the upstream dtc package we get these errors without it:
Configuring for smdk5250 board... In file included from fdt_host.h:24:0, from mkimage.h:35, from aisimage.c:27: ../include/libfdt.h: In function ‘fdt_setprop_inplace_u32’: ../include/libfdt.h:885:2: error: unknown type name ‘fdt32_t’ ../include/libfdt.h: In function ‘fdt_setprop_inplace_u64’: ../include/libfdt.h:920:2: error: unknown type name ‘fdt64_t’ ../include/libfdt.h: In function ‘fdt_property_u32’: ../include/libfdt.h:996:2: error: unknown type name ‘fdt32_t’ ../include/libfdt.h: In function ‘fdt_property_u64’: ../include/libfdt.h:1001:2: error: unknown type name ‘fdt64_t’ ../include/libfdt.h: In function ‘fdt_setprop_u32’: ../include/libfdt.h:1157:2: error: unknown type name ‘fdt32_t’ ../include/libfdt.h: In function ‘fdt_setprop_u64’: ../include/libfdt.h:1192:2: error: unknown type name ‘fdt64_t’ ../include/libfdt.h: In function ‘fdt_appendprop_u32’: ../include/libfdt.h:1299:2: error: unknown type name ‘fdt32_t’ ../include/libfdt.h: In function ‘fdt_appendprop_u64’: ../include/libfdt.h:1334:2: error: unknown type name ‘fdt64_t’
Can this be considered for the release please?
Regards, Simon
Hi Simon,
On 04/12/2013 04:24 PM, Simon Glass wrote:
Hi Tom / Jerry,
[snip]
Another way to fix this is to use -nostdinc and -idirafter to ensure that system includes are included after U-Boot ones. Unfortunately this means that U-Boot's errno.h gets included instead of the system one. This in turn requires a hack to errno.h to redirect things, so all in all the solution in this patch is probably cleaner.
[snip]
Can this be considered for the release please?
This appears to be a reasonable request to fix an outstanding bug. I don't have time today or tomorrow, but I'll pull in your patch and move it forward, Tom willing.
Regards, Simon
Thanks, gvb
On Mon, Mar 11, 2013 at 09:30:27AM -0700, Simon Glass wrote:
When building host utilities, we include libfdt.h from the host, not from U-Boot. This in turn brings in libfdt_env.h from the host, which can mess up the types and cause a build failure, depending on the host environment. To fix this, force inclusion of U-Boot's libfdt_env.h so that the types are correct.
Another way to fix this is to use -nostdinc and -idirafter to ensure that system includes are included after U-Boot ones. Unfortunately this means that U-Boot's errno.h gets included instead of the system one. This in turn requires a hack to errno.h to redirect things, so all in all the solution in this patch is probably cleaner.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
Hi Simon,
On Wed, Apr 17, 2013 at 10:35 AM, Tom Rini trini@ti.com wrote:
On Mon, Mar 11, 2013 at 09:30:27AM -0700, Simon Glass wrote:
When building host utilities, we include libfdt.h from the host, not from U-Boot. This in turn brings in libfdt_env.h from the host, which can mess up the types and cause a build failure, depending on the host environment. To fix this, force inclusion of U-Boot's libfdt_env.h so that the types are correct.
Another way to fix this is to use -nostdinc and -idirafter to ensure that system includes are included after U-Boot ones. Unfortunately this means that U-Boot's errno.h gets included instead of the system one. This in turn requires a hack to errno.h to redirect things, so all in all the solution in this patch is probably cleaner.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
-- Tom
For me this patch causes a regression that looks like this:
Configuring for sandbox board... aisimage.c: In function âaisimage_generateâ: aisimage.c:314: warning: implicit declaration of function âgetlineâ imximage.c: In function âparse_cfg_fileâ: imximage.c:424: warning: implicit declaration of function âgetlineâ kwbimage.c: In function âkwdimage_set_ext_headerâ: kwbimage.c:236: warning: implicit declaration of function âgetlineâ pblimage.c: In function âpbl_parserâ: pblimage.c:119: warning: implicit declaration of function âgetlineâ ublimage.c: In function âparse_cfg_fileâ: ublimage.c:179: warning: implicit declaration of function âgetlineâ
Did you not see this? I see it on ARM, PPC, and sandbox.
-Joe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/14/2013 10:56 AM, Joe Hershberger wrote:
Hi Simon,
On Wed, Apr 17, 2013 at 10:35 AM, Tom Rini trini@ti.com wrote:
On Mon, Mar 11, 2013 at 09:30:27AM -0700, Simon Glass wrote:
When building host utilities, we include libfdt.h from the host, not from U-Boot. This in turn brings in libfdt_env.h from the host, which can mess up the types and cause a build failure, depending on the host environment. To fix this, force inclusion of U-Boot's libfdt_env.h so that the types are correct.
Another way to fix this is to use -nostdinc and -idirafter to ensure that system includes are included after U-Boot ones. Unfortunately this means that U-Boot's errno.h gets included instead of the system one. This in turn requires a hack to errno.h to redirect things, so all in all the solution in this patch is probably cleaner.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
-- Tom
For me this patch causes a regression that looks like this:
Configuring for sandbox board... aisimage.c: In function âaisimage_generateâ: aisimage.c:314: warning: implicit declaration of function âgetlineâ imximage.c: In function âparse_cfg_fileâ: imximage.c:424: warning: implicit declaration of function âgetlineâ kwbimage.c: In function âkwdimage_set_ext_headerâ: kwbimage.c:236: warning: implicit declaration of function âgetlineâ pblimage.c: In function âpbl_parserâ: pblimage.c:119: warning: implicit declaration of function âgetlineâ ublimage.c: In function âparse_cfg_fileâ: ublimage.c:179: warning: implicit declaration of function âgetlineâ
Did you not see this? I see it on ARM, PPC, and sandbox.
Nope. What toolchains?
- -- Tom
participants (4)
-
Jerry Van Baren -
Joe Hershberger -
Simon Glass -
Tom Rini