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.

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

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to