homepage

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:
} ffi_closure __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:
#0 0xfeb50ad4 in ffi_closure_SYSV_inner ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
#1 0xfeb50cca in ffi_closure_SYSV ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
#2 0xfe9d141f in _testfunc_callback_i_if ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes_test.so
#3 0xfeb50c4f in ffi_call_SYSV ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
#4 0xfeb50aa4 in ffi_call ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
#5 0xfeb4b440 in _call_function_pointer ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
#6 0xfeb4baa0 in _CallProc ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
#7 0xfeb483ea in CFuncPtr_call ()
 from
/export/home/skipm/python-sunstudio/lib/python2.4/site-packages/_ctypes.so
#8 0xfeeb23ba in PyObject_Call ()
 from /export/home/skipm/python-sunstudio/lib/libpython2.4.so.1.0
#9 0xfef16c38 in do_call ()
 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.
http://sourceware.org/ml/libffi-discuss/2010/msg00016.html 

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.