[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Max Filippov]

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

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
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

diff --git a/package/uboot-tools/0004-Pass-empty-CFLAGS-on-invocation-of-libfdt-setup.py.patch b/package/uboot-tools/0004-Pass-empty-CFLAGS-on-invocation-of-libfdt-setup.py.patch
new file mode 100644
index 0000000..ae01b33
--- /dev/null
+++ b/package/uboot-tools/0004-Pass-empty-CFLAGS-on-invocation-of-libfdt-setup.py.patch
@@ -0,0 +1,36 @@
+From 7807af13118eff3ac291bbaaf2159c7a441c0902 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+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 <jcmvbkbc@gmail.com>
+Reviewed-by: Simon Glass <sjg@chromium.org>
+---
+ 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

[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Thomas Petazzoni]

Hello,

On Fri, 17 Mar 2017 09:42:42 -0700, Max Filippov wrote:
> 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
> 
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
> Upstream status: fix is posted to the list.

Applied to master, thanks.

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

[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Thomas Petazzoni]

Hello,

On Fri, 17 Mar 2017 09:42:42 -0700, Max Filippov wrote:
> 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
> 
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>

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

[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Max Filippov]

Thomas,

On Mon, Mar 20, 2017 at 2:57 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> There is still an issue with this:
>
>   http://autobuild.buildroot.net/results/eaf/eaf4e5ffc1b2dc3890c529f9d5a0d7e8b6813500/build-end.log

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>

[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Thomas Petazzoni]

Hello,

On Mon, 20 Mar 2017 16:30:53 -0700, Max Filippov wrote:

> 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?

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

[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Max Filippov]

Hi Thomas,

On Wed, Mar 22, 2017 at 2:01 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Mon, 20 Mar 2017 16:30:53 -0700, Max Filippov wrote:
>
>> 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?
>
> 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?

we probably don't.

> 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.

That looks like a nice small fix.

-- 
Thanks.
-- Max

[Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py

[Arnout Vandecappelle]

On 23-03-17 00:12, Max Filippov wrote:
> Hi Thomas,
> 
> On Wed, Mar 22, 2017 at 2:01 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> On Mon, 20 Mar 2017 16:30:53 -0700, Max Filippov wrote:
>>
>>> 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?
>>
>> 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?
> 
> we probably don't.
> 
>> 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? 

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

 Regards,
 Arnout


>> Alternatively, changing:
>>
>>         mv _libfdt.so $@
>>
>> to:
>>
>>         mv _libfdt.*so $@
>>
>> does the trick.
> 
> That looks like a nice small fix.
> 

-- 
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