Cyd Haselton added the comment:

Question for Ryan Gonzalez:
Given this information...

On August 20, 2015 8:03:13 PM CDT, Russell Keith-Magee <> 
>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.
> 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 

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


Python tracker <>
Python-bugs-list mailing list

Reply via email to