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

[Stefan Agner]

On 2017-04-03 10:35, Stefano Babic wrote:
> Hi Stefan,
> 
> On 03/04/2017 18:41, Stefan Agner wrote:
>> 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.
> 
> Quite. I forget to mention...
> 
>> As far as I can see we call
>> setup.py in tools/Makefile using python explicitly:
> 
> Exactly. This makes PYTHON workless.
> 
>>
>> 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.
>>
> 
> No, but we are using "python" that can be taken just from PATH and not
> from the PYTHON variable.
> 
>> Not sure though whether a call to "python" is different in that case
>> from using "/usr/bin/env python"
> 
> I am not sure, too, but I am expecting that shebangs is not evaluated
> because python is already running. But this breaks when I build in

I am expecting that too.

> Yocto, because I cannot override with "PYTHON=nativepython" the default
> interpreter.

But then, I don't expect that "/usr/bin/env python" is looking at
PYTHON.

As far as I understand env, it just looks up the current environment to
run its COMMAND argument. It is helpful as a shebang, but it does not
seem to make any difference to calling "python" directly (since that
also just looks up the current environment PATH and executes the first
python it finds...

--
Stefan