Hi Stefano,
On 2017-04-03 03:30, Stefano Babic wrote:
Hi Stefan,
On 29/03/2017 21:41, Stefan Agner wrote:
From: Stefan Agner stefan.agner@toradex.com
For some reason Python 3 seems to think it does not need to build the library. Using the --force parameter makes sure that the library gets built always. This is especially important since we move the library in the next step of the Makefile, hence forcing a rebuild every time the higher level Makefile triggers a rebuild is required to make sure the library is always there.
Signed-off-by: Stefan Agner stefan.agner@toradex.com
lib/libfdt/setup.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/libfdt/setup.py b/lib/libfdt/setup.py index 62e7bcc1ac..845a0c2b10 100644 --- a/lib/libfdt/setup.py +++ b/lib/libfdt/setup.py @@ -27,7 +27,7 @@ libfdt_module = Extension( extra_compile_args = cflags )
-sys.argv = [progname, '--quiet', 'build_ext', '--inplace'] +sys.argv = [progname, '--quiet', 'build_ext', '--inplace', '--force']
setup (name = 'libfdt', version = '0.1',
It looks to me we have a genaral problem about which python is called. In fact, I am getting another issue when I build 2017.03 in Yocto. The headers like "Python.h" are taken from the distro, and not from the Yocto's buildsystem (nativepython), that makes them available.
It can be easy tested removing the package "libpython" from the host. A "bitbake u-boot", when u-boot 2017.03 is available, fails because no headers are found - but they are all available in Yocto's toolchain.
We set the "PYTHON" variable in the makefile, but this is not used consistent, as far as I see, because in some files as setup.py, "/usr/bin/env python" points to the python installed on distro - adding
Not sure whether that conclusion is correct. As far as I can see we call setup.py in tools/Makefile using python explicitly:
tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= python $(srctree)/lib/libfdt/setup.py \ "$(_hostc_flags)" $^ mv _libfdt.so $@
So we are not using /usr/bin/env in this case.
Not sure though whether a call to "python" is different in that case from using "/usr/bin/env python"
-- Stefan