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 subscrib
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
O
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 an
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 was
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*
> |
> _PYTHON_PROJECT_BASE=/pro
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*
|
_PYTHON_PROJECT_BASE=/projects/yocto-git/build/tmp/work/haswell-diags-linux/python/2.
Ah sorry, I misspoke. I walked through the Makefile and configure scripts a
bit more, and $(PYTHON_FOR_BUILD) should in fact be a host version of
Python. It seems it's not being configured correctly. Either the path is
setup wrong and python2.7 is not pointing to the right version, or
python2.7 nee
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 mod
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
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 stops.
The alternative would be something is runn
11 matches
Mail list logo