[U-Boot] [PATCH] libfdt: fix build with Python 3

[Stefan Agner]

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