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 <[email protected]>

---
 tools/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

tools/Makefile +2 -2

index c5952fc..889c897 100644
@@ -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

Hi Tom / Jerry,

Quoted 5 lines

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.

Can this be considered for the release please?

Regards,
Simon

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 <[email protected]>

Quoted 12 lines · Simon Glass

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.

Quoted 1 line

Signed-off-by Simon Glass <[email protected]>

Applied to u-boot/master, thanks!

--
Tom

Hi Simon,

Quoted 16 lines · Tom Rini

Quoted 14 lines · Simon Glass

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.

Quoted 5 lines

Quoted 1 line

Signed-off-by Simon Glass <[email protected]>

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.