On 2015-07-23 16:42, Burton, Ross wrote:
On 23 July 2015 at 23:38, Gary Thomas <g...@mlbassoc.com
<mailto:g...@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
------------------------------------------------------------
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
