Frank Schaefer added the comment:
Well, after perusing the ctypes callproc.c code, I found the hacks referenced
by martin.panter and tried activating them with some SPARC64 #ifdefs:
--- python3.6-3.6.6.orig/Modules/_ctypes/callproc.c
+++ python3.6-3.6.6/Modules/_ctypes/callproc.c
@@ -1041,6
Frank Schaefer added the comment:
FYI the libffi bug report is open here:
https://github.com/libffi/libffi/issues/451
As noted in the bug report, this issue actually doesn't appear to impact ARM64
(or ARM32 GNUEABI/GNUEABIHF).
--
___
P
Frank Schaefer added the comment:
Further details:
I cloned libffi from a few days ago to see if I had any different behavior. So
far the test fails the same way with the updated libffi.
I'll also see about contacting libffi upstream and see what they can suggest
New submission from Frank Schaefer :
Python 3.6.6 on Linux 4.16.18 SPARC64 fails test_ctypes. Specifically, it
appears to be due to the _testfunc_large_struct_update_value() or
_testfunc_reg_struct_update_value():
0:00:44 load avg: 46.24 [137/407/1] test_ctypes failed -- running
Frank Schaefer added the comment:
This patch alone is apparently not enough. When this is enabled, and python
2.7.10 is built with -mabi=n32, make test segfaults on test_ctypes. Using
--with(out)-system-ffi does not make a difference.
When I run the test by itself, it specifically fails at
