Cyd Haselton added the comment: Question for Ryan Gonzalez: Given this information...
On August 20, 2015 8:03:13 PM CDT, Russell Keith-Magee <rep...@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 <rep...@bugs.python.org> ><http://bugs.python.org/issue23496> >_______________________________________ ---------- _______________________________________ 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
