On August 21, 2015 9:25:10 AM CDT, Cyd Haselton <report@bugs.python.org> wrote:
>
>Cyd Haselton added the comment:
>
>Question for Ryan Gonzalez:
>Given this information...
>
>On August 20, 2015 8:03:13 PM CDT, Russell Keith-Magee
><report@bugs.python.org> wrote:
>>
>>Russell Keith-Magee added the comment:
>>
>>>>What hardware architecture are you compiling for? If it's ARM64, and
>>you're not using a trunk version of libffi, that segfault in
>>test_ctypes is to be expected.
>>
>>> Does this mean I can safely ignore the segfault?
>>
>>Well, "safely" in the sense that everything except a very recent
>>version of libffi is known to not work on ARM64 - so if it doesn't
>>work, it's not because of something Python is doing wrong, it's a
>>problem with a dependency.
>>
>
>...do you know of a way to run all tests except _ctypes, so that Imcan
>verify everything else?
>

You can temporarily change the last line of Lib/ctypes/test/__init__.py to:

return args[1]

>And to answer Russell's questions:
>
>>>>Are you using the libffi sources vendored into the Python source
>>tree, or a more recent version? 
>>
>>>By 'vendored in' do you mean 'sources included in python source tree
>>for building?'
>>
>>Correct. The libffi source code that is in the Python source tree is
>>quite old, and *definitely* doesn't work on ARM64. I'm not even sure
>>that it works on ARMv7.
>>
>Definitely using the vendored in sources.
>
>>
>>> Would your recommend downloading and building libffi from sources
>(on
>>device) and then building python?
>>
>>Well, for starters - as I've said before, I'd recommend not compiling
>>on device at all, but that's a separate issue. 
>>
>Any particular reason why? The device I'm working with has a port of
>GCC which I've used to build other utilities that work well...given
>that I'm working on a tablet.
>
>>However, regardless of where you're compiling, you can either use an
>>external libffi, or you can do what I've done in the iOS patch -
>update
>>the Python source tree to include a newer version of libffi. If you
>>update the source in the Python tree, you need to use 2 versions (or a
>>merged version); you need v3.2 sources for ARMv7, and trunk sources
>for
>>ARM64. This is because libffi v3.2 doesn't work for ARM64, and trunk
>>doesn't even compile for ARMv7. See the iOS patch for details.
>>
>Since I'm not compiling for ARM64...and have zero experience with
>hacking configure.ac files...would it be okay to include just the 3.2
>sources if I note somewhere that this fork does not include ARM64
>support?
>
>>> I'm asking the above questions because I've hit a fairly significant
>>roadblock; I'm still getting the segfault when test_ctypes is run and
>I
>>can't seem to get anything useful out of gdb.
>>
>>Personally, I've pretty much given up on CPython on Android. Even when
>>I got it working, the performance of the JNI layer is *abysmal*, and
>>severely crippled. If you're planning to actually interact with the
>>device in any way (like, say, put a button on the screen), that's a
>big
>>problem. 
>>
>My goal is to build a port that operates on Android in a Linux-like
>environment; I'm currently using KBOX3.  I've no experience with the
>Python language so JNI interop is Greek to me.  For what i'm using the
>port for it functions fairly well.
>
>>I'm working on an approach that uses Java natively - think "Jython for
>>Android". I'm still a way off having anything working, though.
>>
>I'll keep an eye out for it once I've got Python basics under my belt.
>>----------
>>
>>_______________________________________
>>Python tracker <report@bugs.python.org>
>><http://bugs.python.org/issue23496>
>>_______________________________________
>
>----------
>
>_______________________________________
>Python tracker <report@bugs.python.org>
><http://bugs.python.org/issue23496>
>_______________________________________