Closed 3807ddda-7a46-46c2-9a7e-24172362f2cc closed 13 years ago
The _ctypes modules fails to compile on Solaris 10 x86 32-bit using the Sun Studio 11 compiler. _ctypes does compile successfully using gcc. The error messages are attached. If needed, I can provide access to the machine.
Logged In: YES user_id=1212585
I have tracked down two issues. First Sun's cc compiler does defines __386 instead of __386__. This causes problems in ffitarget.h
Second, Sun's cc compiler fails on the following line in ffi.h: } fficlosure \_attribute__((aligned (8)));
This is a problem in Sun's cc compiler. It is fixed in the Sun Studio Express August 2006 release. I don't think there is a patch for the "official" Sun Studio 11 compiler.
With these two changes, ctypes does compile but "make test" still fails. I am still researching the "make test" failure. test_crypt test_csv test_ctypes sh: objdump: not found *** Signal 11 - core dumped make: Fatal error: Command failed for target `test' bash-3.00$
You can at least see which test(s) crashes when you run the ctypes tests in this way:
./python Lib/ctypes/test/runtests.py -v
FWIW, ctypes builds on trunk and all its tests pass with Sun Studio 12. I suspect this issue can be closed but will leave that for Thomas to decide.
Though I should note that ctypes 1.0.2 won't build with Sun Studio 12 on Python 2.4 without some patches for the __i386 macro in ffitarget.h. I added this check near the top of ffitarget.h:
#ifdef __i386
/* Sun Studio 12 */
#define __i386__
#endif
*argh* segfault running tests w/ Sun Studio 12 compiled version of ctypes 1.0.2:
% python ctypes/test/runtests.py -v sh: objdump: not found find_library('c') -> sh: objdump: not found None find_library('m') -> sh: objdump: not found None test_anon (ctypes.test.test_anon.AnonTest) ... ok test_anon_nonmember (ctypes.test.test_anon.AnonTest) ... ok test_anon_nonseq (ctypes.test.test_anon.AnonTest) ... ok test_nested (ctypes.test.test_anon.AnonTest) ... ok test (ctypes.test.test_array_in_pointer.Test) ... ok test_2 (ctypes.test.test_array_in_pointer.Test) ... ok test_classcache (ctypes.test.test_arrays.ArrayTestCase) ... ok test_from_address (ctypes.test.test_arrays.ArrayTestCase) ... ok test_from_addressW (ctypes.test.test_arrays.ArrayTestCase) ... ok test_numeric_arrays (ctypes.test.test_arrays.ArrayTestCase) ... ok test_simple (ctypes.test.test_arrays.ArrayTestCase) ... ok test_byval (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... oktest_callbacks (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... Segmentation Fault
Beginning of backtrace:
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes_test.so
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
from /export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
from /export/home/skipm/python-sunstudio/lib/libpython2.4.so.1.0
from /export/home/skipm/python-sunstudio/lib/libpython2.4.so.1.0
I've stumbled head-first into this bug trying to build ctypes 1.0.2, as required by the python Shapely GIS library for an important Zope project I've been working on.
It's a real surprise to see this bug even exists (since 2006!). I don't understand the cause, but it's totally preventing me from deploying code using Shapely (and therefore ctypes) to a new Solaris x86 server that otherwise runs on Windows and Linux right now.
How come no progress - is it too hard to solve?
I'm using Sun Studio 12.1. Out of a bunch of core libraries we're using (numpy, geos etc), this little package that has been "accepted" into the main Python distro seems to be the only one we've had problems with. :-(
Is there really no way around this?
Hello is this not the fix? Are there any plans for patch and ctypes 1.0.3? ctypes is a setuptools dependency for various Python 3rd party packages, and this breaks any that enlist ctypes on Solaris.
Can you please try the subversion trunk of Python, and report whether this works for you?
Unfortunately I also get core dump applying that patch alone.
core 'core' of 12847: /usr/local/Python-2.4.6-SunCC/bin/python setup.py test feaf0cfe ffi_call_SYSV (fefb0fc8, 8045898, feaf0b08, feaf08e4, 8045880, 4) + 66 feaf0caf ffi_call_SYSV (feaf08e4, 8045880, 4, 1, 8045920, fe95133c) + 17 feaf0b08 ffi_call (80458b0) + 64 feaeb47a _call_function_pointer (1001, fe95133c, 8045910, 8045900, 82a27bc, 804 5920) + 86 feaebad0 _CallProc (fe95133c, 842298c, 1001, 0, 82e1e74, 0) + 2dc feae8408 CFuncPtr_call (83fe304, 842298c, 0, 8422a6c) + 190 08063423 PyObject_Call (83fe304, 842298c, 0, 8063423) + 23 080b308c do_call (83fe304, 8045aec, 1, 0) + 54 080b2806 call_function (8045aec, 1, cd24f104, 82ca2cc) + ae 080afd91 PyEval_EvalFrame (8275154, 815ded4, 82b30b4, 0) + 27a1 080b1782 PyEval_EvalCodeEx (82ba460, 82b30b4, 0, 8262388, 1, 826238c) + 8ba 080b2cd6 fast_function (82ca2cc, 8045c9c, 1, 1, 0, 80f1740) + 15a 080b2822 call_function (8045c9c, 0, a0, 0) + ca
nick: not sure what "this patch" is that you tried applying. What about Python trunk?
Martin, the patch is for libffi included in ctypes 1.0.2. This is python 2.4 (required for plone/zope) so python 2.5/2.6 etc is not a possibility.
ctypes 1.0.2 compiles with this patch but then core dumps anyway during tests so false hope.
It appears to me that no-one is maintaining this separate ctypes code-base anymore so I'll have to ditch dependencies that use it (Shapely) unfortunately.
It appears to me that no-one is maintaining this separate ctypes code-base anymore so I'll have to ditch dependencies that use it (Shapely) unfortunately.
This is correct, the separate ctypes code base is linked via svn:external into the core Python svn repository. Unfortunately, the Python trunk ctypes code does not compile with earlier Python versions any more.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields: ```python assignee = 'https://github.com/theller' closed_at =
created_at =
labels = ['ctypes', 'build', 'type-crash']
title = '_ctypes fails to build on Solaris x86 32-bit (Sun compiler)'
updated_at =
user = 'https://bugs.python.org/casevh'
```
bugs.python.org fields:
```python
activity =
actor = 'terry.reedy'
assignee = 'theller'
closed = True
closed_date =
closer = 'terry.reedy'
components = ['Build', 'ctypes']
creation =
creator = 'casevh'
dependencies = []
files = ['2123', '14595']
hgrepos = []
issue_num = 1544339
keywords = []
message_count = 13.0
messages = ['29607', '29608', '29609', '75316', '75317', '75318', '91036', '101485', '101493', '101550', '101552', '101563', '101594']
nosy_count = 7.0
nosy_names = ['loewis', 'theller', 'casevh', 'mmueller', 'edsu', 'dchud', 'nick']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue1544339'
versions = ['Python 2.6', 'Python 2.5', 'Python 2.4']
```