Mark, I am continuing to look at this. I hope you don't mind if I keep
updating this thread with my investigation.
First, I figured out my confusion. I was associating the wrong Makefile
command with the illegal instruction. It was actually the command under the
recipe for 'sharedmods', but it
This is the patch that we ended up using:
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/113457.html
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/113456.html
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/113458.html
OK I've dug into this further today, and here are some findings:
With my patch (which is similar to yours), it fails do_compile/package_qa
because of poisoned system directories during the compilation steps. This
approach seems to be a bust. Originally when I tested it, I hacked up the
Makefile
Mark, great! I was literally about to try double-stacking the PATH next
(since removing both didn't work for reasons that became obvious after
running the experiment), so that it would grab the *.so's from
python-native and then the sysconfig from the python-cross. Looks like I
may need to
For what it's worth, this is the offending portion of Makefile.pre:452:
# Create build directory and generate the sysconfig build-time data there.
# pybuilddir.txt contains the name of the build dir and is used for
# sys.path fixup -- see Modules/getpath.c.
# Since this step runs before shared
Well, I'm wrong yet again. A 'which python2.7' shows that it's pointing to
a native version of Python:
*| which python2.7*
*|
/projects/yocto-git/build/tmp/sysroots/x86_64-linux/usr/bin/python-native/python2.7*
|
Mark,
I ran the same command, including the offending PYTHONPATH, from the shell
without error. Any reason why that would work, despite it not working from
within the Makefile? I was thinking it was another environment variable
that was causing the issue (one that's not set in my bash environment
On 11/25/15 10:11 AM, Michael Habibi wrote:
> Well, I'm wrong yet again. A 'which python2.7' shows that it's pointing to a
> native version of Python:
>
> *| which python2.7*
> *|
> /projects/yocto-git/build/tmp/sysroots/x86_64-linux/usr/bin/python-native/python2.7*
> |
>
On 11/24/15 3:23 PM, Mark Hatle wrote:
> My guess is that there is a bug in the python integration where it's not
> realizing the host and target are different systems, so it's trying to run a
> target program on your host. Your host isn't haswell, so... Illegal
> Instruction
> -- and the system
