[PATCH] libepoxy: Use native python3

[PATCH] libepoxy: Use native python3

[Gary Thomas]

This recipe needs python3.  This patch arranges to use the bitbake-built
version, not the host version (which may be missing or not work...)

Signed-off-by: Gary Thomas <gary@mlbassoc.com>
---
 meta/recipes-graphics/libepoxy/libepoxy_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/libepoxy/libepoxy_git.bb b/meta/recipes-graphics/libepoxy/libepoxy_git.bb
index 9816257..0330a7b 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_git.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_git.bb
@@ -16,7 +16,7 @@ PV = "1.2+git${SRCPV}"
 
 S = "${WORKDIR}/git"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig python3native
 
 DEPENDS = "util-macros virtual/egl"
 
-- 
1.9.1

Re: [PATCH] libepoxy: Use native python3

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On 23 July 2015 at 01:22, Gary Thomas <gary@mlbassoc.com> wrote:

> This recipe needs python3.  This patch arranges to use the bitbake-built
> version, not the host version (which may be missing or not work...)
>

Needs is a strong word.  The configure script does this:

AC_CHECK_PROGS([PYTHON], [python3 python2 python])

What's actually happening as a patch to simply remove python3 from that
list will also solve most problems - we obviously depend on a fully working
host python 2.

Ross

[-- Attachment #2: Type: text/html, Size: 2015 bytes --]

Re: [PATCH] libepoxy: Use native python3

[Gary Thomas]

On 2015-07-23 16:33, Burton, Ross wrote:
>
> On 23 July 2015 at 01:22, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>
>     This recipe needs python3.  This patch arranges to use the bitbake-built
>     version, not the host version (which may be missing or not work...)
>
>
> Needs is a strong word.  The configure script does this:
>
> AC_CHECK_PROGS([PYTHON], [python3 python2 python])
>
>
> What's actually happening as a patch to simply remove python3 from that list will also solve most problems - we obviously depend on a fully working host python 2.

Well for me, the configure script ended up chosing python3,
even when I used 'pythonnative' (i.e. python2) in the recipe.
I could not get it to build any other way.

Since python3-native will most likely already be built, what's
the harm in doing it this way?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [PATCH] libepoxy: Use native python3

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On 23 July 2015 at 23:38, Gary Thomas <gary@mlbassoc.com> wrote:

> Well for me, the configure script ended up chosing python3,
> even when I used 'pythonnative' (i.e. python2) in the recipe.
> I could not get it to build any other way.
>
> Since python3-native will most likely already be built, what's
> the harm in doing it this way?
>

Why will it be build?  I certainly don't have a python3 build here.

Inheriting pythonnative is also the wrong thing to do - the pythonnative
classes are solely for when you need to run Python and use non-standard
classes that you've already built natively.  If you just want to run the
host Python, let it find the host python.

Why was the configure script choosing python3 on your host the wrong thing
to do?

Ross

[-- Attachment #2: Type: text/html, Size: 1332 bytes --]

Re: [PATCH] libepoxy: Use native python3

[Gary Thomas]

On 2015-07-23 16:42, Burton, Ross wrote:
>
> On 23 July 2015 at 23:38, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>
>     Well for me, the configure script ended up chosing python3,
>     even when I used 'pythonnative' (i.e. python2) in the recipe.
>     I could not get it to build any other way.
>
>     Since python3-native will most likely already be built, what's
>     the harm in doing it this way?
>
>
> Why will it be build?  I certainly don't have a python3 build here.

I almost always seem to end up with it being built...

>
> Inheriting pythonnative is also the wrong thing to do - the pythonnative classes are solely for when you need to run Python and use non-standard classes that you've already built
> natively.  If you just want to run the host Python, let it find the host python.
>
> Why was the configure script choosing python3 on your host the wrong thing to do?

It seems that my host python3 is broken and doesn't have a working 'argparse'
   $ python3
   Python 3.1.2 (r312:79147, Aug 23 2010, 05:17:13)
   [GCC 4.4.4 20100630 (Red Hat 4.4.4-10)] on linux2
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import argparse
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   ImportError: No module named argparse
It's an old host (Fedora 13) that I am unable to upgrade, but it still
works quite well.  I get around most of the Yocto/bitbake worries by
using a Yocto-built meta-toolchain to fill in the blanks (correct make,
python2, etc), but python3 is not part of the meta-toolchain :-(

If this is not the correct way to get libepoxy to build, fair enough,
I'll figure out how to make my host "functional".

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [PATCH] libepoxy: Use native python3

[Richard Purdie]

On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:
> It's an old host (Fedora 13) that I am unable to upgrade, but it still
> works quite well.  I get around most of the Yocto/bitbake worries by
> using a Yocto-built meta-toolchain to fill in the blanks (correct make,
> python2, etc), but python3 is not part of the meta-toolchain :-(

You could likely build a customised meta-toolchain which did contain
python3 though?

Cheers,

Richard

Re: [PATCH] libepoxy: Use native python3

[Gary Thomas]

On 2015-07-23 17:06, Richard Purdie wrote:
> On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:
>> It's an old host (Fedora 13) that I am unable to upgrade, but it still
>> works quite well.  I get around most of the Yocto/bitbake worries by
>> using a Yocto-built meta-toolchain to fill in the blanks (correct make,
>> python2, etc), but python3 is not part of the meta-toolchain :-(
>
> You could likely build a customised meta-toolchain which did contain
> python3 though?

Do you know how I would make that happen?  For me, meta-toolchain is
a black box - I know very little of the internals.

Question about policy: it seems that a good many "native" packages
are built, many just to "level the playing field".   I just checked
and one of my average builds has 148 native packages sitting there.
For example, why build bison-native when my host's bison is even the
same vintage and hence just as adequate?  Why then, draw the line
over python3 in this one recipe?  (Just asking, I'll figure out how
to fix this anyway)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [PATCH] libepoxy: Use native python3

[Richard Purdie]

On Thu, 2015-07-23 at 17:15 -0600, Gary Thomas wrote:
> On 2015-07-23 17:06, Richard Purdie wrote:
> > On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:
> >> It's an old host (Fedora 13) that I am unable to upgrade, but it still
> >> works quite well.  I get around most of the Yocto/bitbake worries by
> >> using a Yocto-built meta-toolchain to fill in the blanks (correct make,
> >> python2, etc), but python3 is not part of the meta-toolchain :-(
> >
> > You could likely build a customised meta-toolchain which did contain
> > python3 though?
> 
> Do you know how I would make that happen?  For me, meta-toolchain is
> a black box - I know very little of the internals.

Personally, I'd probably use "buildtools-tarball" for this so I'd go and
edit the buildtools-tarball.bb file and add nativesdk-python3-modules to
it which should pull in the bulk of python3 (not sure if you'd need
nativesdk-python3-core too, I'd hope that would be automatic from the
other).

You prefer your meta-toolchain? Then set:
TOOLCHAIN_HOST_TASK_append = " nativesdk-python3-modules"
in local.conf and it should add python3 to all meta-toolchain builds.

> Question about policy: it seems that a good many "native" packages
> are built, many just to "level the playing field".   I just checked
> and one of my average builds has 148 native packages sitting there.
> For example, why build bison-native when my host's bison is even the
> same vintage and hence just as adequate?  Why then, draw the line
> over python3 in this one recipe?  (Just asking, I'll figure out how
> to fix this anyway)

The line is drawn over python. Bitbake is built with python (2 at the
moment, 3 in the future) and since we need python to run bitbake,
rebuilding it seems silly. Yes, we do need to build a python-native to
be able to build python (target) which is sad but such is the nature of
cross compiling. We therefore tend to assume the provided python(s) are
sane.

Cheers,

Richard

Re: [PATCH] libepoxy: Use native python3

[Gary Thomas]

On 2015-07-24 01:52, Richard Purdie wrote:
> On Thu, 2015-07-23 at 17:15 -0600, Gary Thomas wrote:
>> On 2015-07-23 17:06, Richard Purdie wrote:
>>> On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:
>>>> It's an old host (Fedora 13) that I am unable to upgrade, but it still
>>>> works quite well.  I get around most of the Yocto/bitbake worries by
>>>> using a Yocto-built meta-toolchain to fill in the blanks (correct make,
>>>> python2, etc), but python3 is not part of the meta-toolchain :-(
>>>
>>> You could likely build a customised meta-toolchain which did contain
>>> python3 though?
>>
>> Do you know how I would make that happen?  For me, meta-toolchain is
>> a black box - I know very little of the internals.
>
> Personally, I'd probably use "buildtools-tarball" for this so I'd go and
> edit the buildtools-tarball.bb file and add nativesdk-python3-modules to
> it which should pull in the bulk of python3 (not sure if you'd need
> nativesdk-python3-core too, I'd hope that would be automatic from the
> other).

Sadly, this failed:
| Objects/obmalloc.o: In function `_PyObject_DebugMallocStats':
| obmalloc.c:(.text+0x1793): undefined reference to `pool_is_in_list'
| collect2: error: ld returned 1 exit status
| make: *** [Parser/pgen] Error 1
| make: *** Waiting for unfinished jobs....
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (log file is located at 
/local/p0382-cutting-edge_2014-11-21/tmp/work/i686-nativesdk-amltdsdk-linux/nativesdk-python3/3.4.3-r1.0/temp/log.do_compile.27165)
ERROR: Task 163 (virtual:nativesdk:/local/poky-cutting-edge/meta/recipes-devtools/python/python3_3.4.3.bb, do_compile) failed with exit code '1'

>
> You prefer your meta-toolchain? Then set:
> TOOLCHAIN_HOST_TASK_append = " nativesdk-python3-modules"
> in local.conf and it should add python3 to all meta-toolchain builds.
>
>> Question about policy: it seems that a good many "native" packages
>> are built, many just to "level the playing field".   I just checked
>> and one of my average builds has 148 native packages sitting there.
>> For example, why build bison-native when my host's bison is even the
>> same vintage and hence just as adequate?  Why then, draw the line
>> over python3 in this one recipe?  (Just asking, I'll figure out how
>> to fix this anyway)
>
> The line is drawn over python. Bitbake is built with python (2 at the
> moment, 3 in the future) and since we need python to run bitbake,
> rebuilding it seems silly. Yes, we do need to build a python-native to
> be able to build python (target) which is sad but such is the nature of
> cross compiling. We therefore tend to assume the provided python(s) are
> sane.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [PATCH] libepoxy: Use native python3

[Gary Thomas]

On 2015-07-24 08:45, Gary Thomas wrote:
> On 2015-07-24 01:52, Richard Purdie wrote:
>> On Thu, 2015-07-23 at 17:15 -0600, Gary Thomas wrote:
>>> On 2015-07-23 17:06, Richard Purdie wrote:
>>>> On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:
>>>>> It's an old host (Fedora 13) that I am unable to upgrade, but it still
>>>>> works quite well.  I get around most of the Yocto/bitbake worries by
>>>>> using a Yocto-built meta-toolchain to fill in the blanks (correct make,
>>>>> python2, etc), but python3 is not part of the meta-toolchain :-(
>>>>
>>>> You could likely build a customised meta-toolchain which did contain
>>>> python3 though?
>>>
>>> Do you know how I would make that happen?  For me, meta-toolchain is
>>> a black box - I know very little of the internals.
>>
>> Personally, I'd probably use "buildtools-tarball" for this so I'd go and
>> edit the buildtools-tarball.bb file and add nativesdk-python3-modules to
>> it which should pull in the bulk of python3 (not sure if you'd need
>> nativesdk-python3-core too, I'd hope that would be automatic from the
>> other).
>
> Sadly, this failed:
> | Objects/obmalloc.o: In function `_PyObject_DebugMallocStats':
> | obmalloc.c:(.text+0x1793): undefined reference to `pool_is_in_list'
> | collect2: error: ld returned 1 exit status
> | make: *** [Parser/pgen] Error 1
> | make: *** Waiting for unfinished jobs....
> | ERROR: oe_runmake failed
> | ERROR: Function failed: do_compile (log file is located at
> /local/p0382-cutting-edge_2014-11-21/tmp/work/i686-nativesdk-amltdsdk-linux/nativesdk-python3/3.4.3-r1.0/temp/log.do_compile.27165)
> ERROR: Task 163 (virtual:nativesdk:/local/poky-cutting-edge/meta/recipes-devtools/python/python3_3.4.3.bb, do_compile) failed with exit code '1'

It seems that python3 doesn't like being built without Py_DEBUG set.
I worked through that only to find this additional error:

Collected errors:
  * satisfy_dependencies_for: Cannot satisfy the following dependencies for nativesdk-python3-modules:
  *      nativesdk-python3-robotparser *
  * opkg_install_cmd: Cannot install package nativesdk-python3-modules.

>
>>
>> You prefer your meta-toolchain? Then set:
>> TOOLCHAIN_HOST_TASK_append = " nativesdk-python3-modules"
>> in local.conf and it should add python3 to all meta-toolchain builds.
>>
>>> Question about policy: it seems that a good many "native" packages
>>> are built, many just to "level the playing field".   I just checked
>>> and one of my average builds has 148 native packages sitting there.
>>> For example, why build bison-native when my host's bison is even the
>>> same vintage and hence just as adequate?  Why then, draw the line
>>> over python3 in this one recipe?  (Just asking, I'll figure out how
>>> to fix this anyway)
>>
>> The line is drawn over python. Bitbake is built with python (2 at the
>> moment, 3 in the future) and since we need python to run bitbake,
>> rebuilding it seems silly. Yes, we do need to build a python-native to
>> be able to build python (target) which is sad but such is the nature of
>> cross compiling. We therefore tend to assume the provided python(s) are
>> sane.
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: [PATCH] libepoxy: Use native python3

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On 24 July 2015 at 00:00, Gary Thomas <gary@mlbassoc.com> wrote:

> It seems that my host python3 is broken and doesn't have a working
> 'argparse'
>   $ python3
>   Python 3.1.2 (r312:79147, Aug 23 2010, 05:17:13)
>

argparse is part of 3.2 onwards (and 2.7 onwards...).  If the script is
going to use functions that only exist in specific versions of Python then
it should really check.  Personally I'd say patching the python check to
only look for "python" or "python2" would be a reasonable workaround.

Ross

[-- Attachment #2: Type: text/html, Size: 966 bytes --]

Re: [PATCH] libepoxy: Use native python3

[Gary Thomas]

On 2015-07-24 09:08, Burton, Ross wrote:
>
> On 24 July 2015 at 00:00, Gary Thomas <gary@mlbassoc.com <mailto:gary@mlbassoc.com>> wrote:
>
>     It seems that my host python3 is broken and doesn't have a working 'argparse'
>        $ python3
>        Python 3.1.2 (r312:79147, Aug 23 2010, 05:17:13)
>
>
> argparse is part of 3.2 onwards (and 2.7 onwards...).  If the script is going to use functions that only exist in specific versions of Python then it should really check.
> Personally I'd say patching the python check to only look for "python" or "python2" would be a reasonable workaround.

I tried that and it worked fine on my [semi-broken-python3] host.

Patch sent.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------