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 freakboy3742
Recipients chaselton, ethan.furman, freakboy3742, mpaolini, r.david.murray, refi64, tritium
Date 2015-08-21.01:03:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
>>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.

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

>>I can verify that libffi v3.2 works on ARMv7 (on iOS, anyway), and there's been plenty of changes to the ARM source tree since the Python version was vendored in.

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

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.

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

I'm working on an approach that uses Java natively - think "Jython for Android". I'm still a way off having anything working, though.
Date User Action Args
2015-08-21 01:03:13freakboy3742setrecipients: + freakboy3742, r.david.murray, ethan.furman, refi64, mpaolini, chaselton, tritium
2015-08-21 01:03:13freakboy3742setmessageid: <>
2015-08-21 01:03:13freakboy3742linkissue23496 messages
2015-08-21 01:03:12freakboy3742create