python / cpython

The Python programming language
https://www.python.org/
Other
60.24k stars 29.15k forks source link

_ctypes fails to build on Solaris x86 32-bit (Sun compiler) #43873

Closed 3807ddda-7a46-46c2-9a7e-24172362f2cc closed 13 years ago

3807ddda-7a46-46c2-9a7e-24172362f2cc commented 17 years ago
BPO 1544339
Nosy @loewis, @theller
Files
  • ctype.txt
  • ffitarget-error.txt: Compiler and pre-processor error.
  • 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'] ```

    3807ddda-7a46-46c2-9a7e-24172362f2cc commented 17 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.

    3807ddda-7a46-46c2-9a7e-24172362f2cc commented 17 years ago

    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$

    theller commented 17 years ago

    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

    smontanaro commented 15 years ago

    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.

    smontanaro commented 15 years ago

    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
    smontanaro commented 15 years ago

    *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

    f504fb4b-db9e-46a8-b0f5-c2eb2f1ffa54 commented 14 years ago

    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?

    f504fb4b-db9e-46a8-b0f5-c2eb2f1ffa54 commented 14 years ago

    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

    61337411-43fc-4a9c-b8d5-4060aede66d0 commented 14 years ago

    Can you please try the subversion trunk of Python, and report whether this works for you?

    f504fb4b-db9e-46a8-b0f5-c2eb2f1ffa54 commented 14 years ago

    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

    61337411-43fc-4a9c-b8d5-4060aede66d0 commented 14 years ago

    nick: not sure what "this patch" is that you tried applying. What about Python trunk?

    f504fb4b-db9e-46a8-b0f5-c2eb2f1ffa54 commented 14 years ago

    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.

    theller commented 14 years ago

    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.