uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

When building u-boot tools in cross-build environment CFLAGS environment variable set up for target is taken into an account when building code for host. Make it empty on invocation of python.

This fixes the following build errors when cross-compiling for xtensa:

cc1: error: unrecognized command line option "-mlongcalls"
cc1: error: unrecognized command line option "-mauto-litpools"

Fixes:
http://autobuild.buildroot.net/results/439d6dacfaa7f9244bd15ca04990c12a25ff4777
http://autobuild.buildroot.net/results/e2fe36c20e75d01a01a6659ef11e888965a843b9
http://autobuild.buildroot.net/results/6f37ff347822a76571a9fe9cf3c491fe7e4164fa

---
Upstream status: fix is posted to the list.

 ...y-CFLAGS-on-invocation-of-libfdt-setup.py.patch | 36 ++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 package/uboot-tools/0004-Pass-empty-CFLAGS-on-invocation-of-libfdt-setup.py.patch

new file mode 100644
index 0000000..ae01b33
@@ -0,0 +1,36 @@
+From 7807af13118eff3ac291bbaaf2159c7a441c0902 Mon Sep 17 00:00:00 2001
+From: Max Filippov <[email protected]>
+Date: Thu, 16 Mar 2017 11:21:58 -0700
+Subject: [PATCH] Pass empty CFLAGS on invocation of libfdt/setup.py
+
+When building u-boot tools in cross-build environment CFLAGS environment
+variable set up for target is taken into an account when building code
+for host. Make it empty on invocation of python.
+
+This fixes the following build errors when cross-compiling for xtensa:
+
+  cc1: error: unrecognized command line option "-mlongcalls"
+  cc1: error: unrecognized command line option "-mauto-litpools"
+
+Signed-off-by: Max Filippov <[email protected]>
+Reviewed-by: Simon Glass <[email protected]>
+---
+ tools/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/Makefile b/tools/Makefile
+index 1c840d7..f3de657 100644
+--- a/tools/Makefile
++++ b/tools/Makefile
+@@ -120,7 +120,7 @@ _libfdt.so-sharedobjs += $(LIBFDT_OBJS)
+ libfdt:
+ 
+ tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c
+-	LDFLAGS="$(HOSTLDFLAGS)" python $(srctree)/lib/libfdt/setup.py \
++	LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= python $(srctree)/lib/libfdt/setup.py \
+ 		"$(_hostc_flags)" $^
+ 	mv _libfdt.so $@
+ 
+-- 
+2.1.4
+

2.1.4

Hello,

Applied to master, thanks.

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Hello,

There is still an issue with this:

http://autobuild.buildroot.net/results/eaf/eaf4e5ffc1b2dc3890c529f9d5a0d7e8b6813500/build-end.log

Best regards,

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Thomas,

I can't reproduce it.
The python script makes the compilation super quiet, can we apply something like the attached patch to see what happens?

Thanks.
-- Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-uboot-tools-make-_libfdt.so-build-verbose.patch
Type: text/x-patch
Size: 1389 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170320/03290926/attachment.bin>

Hello,

Build log is below. The issue is that the library being produced is named _libfdt.cpython-35m-x86_64-linux-gnu.so, but U-Boot build system assumes it's named _libfdt.so.

However, let's take a step back: why the heck do we have this Python related stuff being built? uboot-tools is only meant to install the basic U-Boot tools like fw_printenv and fw_setenv to the target. Why do we bother about this Python libfdt thing? We're not even installing this stuff to the target:

define UBOOT_TOOLS_INSTALL_TARGET_CMDS

        $(UBOOT_TOOLS_INSTALL_MKIMAGE)
        $(UBOOT_TOOLS_INSTALL_MKENVIMAGE)
        $(UBOOT_TOOLS_INSTALL_FWPRINTENV)
        $(UBOOT_TOOLS_INSTALL_DUMPIMAGE)

endef

Looking at tools/Makefile, it indeed automatically builds this Python stuff is swig is available, with no way to disable this stuff. Should we patch this out? Alternatively, changing:

mv _libfdt.so $@

to:

	mv _libfdt.*so $@

does the trick.

Build log of the Python extension:

building '_libfdt' extension
creating build
creating build/temp.linux-x86_64-3.5
creating build/temp.linux-x86_64-3.5/lib
creating build/temp.linux-x86_64-3.5/lib/libfdt
creating build/temp.linux-x86_64-3.5/tools
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c lib/libfdt/fdt.c -o build/temp.linux-x86_64-3.5/lib/libfdt/fdt.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
HOSTLD tools/fdtgrep
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c lib/libfdt/fdt_ro.c -o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_ro.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
HOSTLD tools/dumpimage
HOSTLD tools/mkimage
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c lib/libfdt/fdt_rw.c -o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_rw.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c lib/libfdt/fdt_strerror.c -o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_strerror.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c lib/libfdt/fdt_wip.c -o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_wip.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c lib/libfdt/fdt_region.c -o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_region.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c lib/libfdt/fdt_sw.c -o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_sw.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
/usr/bin/gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/include/python3.5m -c tools/libfdt_wrap.c -o build/temp.linux-x86_64-3.5/tools/libfdt_wrap.o -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch//include -I./lib/libfdt -I./tools -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE
/usr/bin/gcc -pthread -shared -L/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/lib -L/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/lib -Wl,-rpath,/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/lib -Wl,--enable-new-dtags build/temp.linux-x86_64-3.5/lib/libfdt/fdt.o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_ro.o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_rw.o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_strerror.o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_wip.o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_region.o build/temp.linux-x86_64-3.5/lib/libfdt/fdt_sw.o build/temp.linux-x86_64-3.5/tools/libfdt_wrap.o -L/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/host/usr/lib -lpython3.5m -o /home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/build/uboot-tools-2017.03/_libfdt.cpython-35m-x86_64-linux-gnu.so mv _libfdt.so tools/_libfdt.so
mv: cannot stat `_libfdt.so': No such file or directory
make[3]: *** [tools/_libfdt.so] Error 1
make[2]: *** [tools-only] Error 2
make[1]: *** [/home/test/outputs/995a1773efe982ed8443b2c5f9ea40a1ed106472/output/build/uboot-tools-2017.03/.stamp_built] Error 2
make: *** [_all] Error 2

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Hi Thomas,

we probably don't.

That looks like a nice small fix.

Thanks.
-- Max

I would very much prefer an upstreamable patch that makes it possible to
disable this.

Regards,
Arnout

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF