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?

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>
>_______________________________________