* [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py
@ 2017-03-17 16:42 Max Filippov
2017-03-18 13:01 ` Thomas Petazzoni
2017-03-20 21:57 ` Thomas Petazzoni
0 siblings, 2 replies; 7+ messages in thread
From: Max Filippov @ 2017-03-17 16:42 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py
2017-03-17 16:42 [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py Max Filippov
@ 2017-03-18 13:01 ` Thomas Petazzoni
2017-03-20 21:57 ` Thomas Petazzoni
1 sibling, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2017-03-18 13:01 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py
2017-03-17 16:42 [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py Max Filippov
2017-03-18 13:01 ` Thomas Petazzoni
@ 2017-03-20 21:57 ` Thomas Petazzoni
2017-03-20 23:30 ` Max Filippov
1 sibling, 1 reply; 7+ messages in thread
From: Thomas Petazzoni @ 2017-03-20 21:57 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py
2017-03-20 21:57 ` Thomas Petazzoni
@ 2017-03-20 23:30 ` Max Filippov
2017-03-22 21:01 ` Thomas Petazzoni
0 siblings, 1 reply; 7+ messages in thread
From: Max Filippov @ 2017-03-20 23:30 UTC (permalink / raw)
To: buildroot
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py
2017-03-20 23:30 ` Max Filippov
@ 2017-03-22 21:01 ` Thomas Petazzoni
2017-03-22 23:12 ` Max Filippov
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Petazzoni @ 2017-03-22 21:01 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 7+ messages in thread* [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py
2017-03-22 21:01 ` Thomas Petazzoni
@ 2017-03-22 23:12 ` Max Filippov
2017-03-23 8:12 ` Arnout Vandecappelle
0 siblings, 1 reply; 7+ messages in thread
From: Max Filippov @ 2017-03-22 23:12 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py
2017-03-22 23:12 ` Max Filippov
@ 2017-03-23 8:12 ` Arnout Vandecappelle
0 siblings, 0 replies; 7+ messages in thread
From: Arnout Vandecappelle @ 2017-03-23 8:12 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-23 8:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-17 16:42 [Buildroot] [PATCH] uboot-tools: pass empty CFLAGS on invocation of libfdt/setup.py Max Filippov
2017-03-18 13:01 ` Thomas Petazzoni
2017-03-20 21:57 ` Thomas Petazzoni
2017-03-20 23:30 ` Max Filippov
2017-03-22 21:01 ` Thomas Petazzoni
2017-03-22 23:12 ` Max Filippov
2017-03-23 8:12 ` Arnout Vandecappelle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox