This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author refi64
Recipients chaselton, ethan.furman, freakboy3742, mpaolini, r.david.murray, refi64, tritium
Date 2015-08-21.14:48:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On August 21, 2015 9:25:10 AM CDT, Cyd Haselton <> 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
><> 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.
> 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/ 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
>>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 -
>>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
>>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
>>> 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
>>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
>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 <>
Date User Action Args
2015-08-21 14:48:32refi64setrecipients: + refi64, r.david.murray, freakboy3742, ethan.furman, mpaolini, chaselton, tritium
2015-08-21 14:48:32refi64linkissue23496 messages
2015-08-21 14:48:31refi64create