[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Maciej Bliziński added the comment:
The specific case that breaks for me is this:
OpeCSW Python package includes:
/opt/csw/bin/python2.6 (also 2.7, 3.3, etc)
/opt/csw/lib/libpython2.6.so.1.0
(other files)
On the operating system there is only:
/usr/lib/libpython2.4.so.1.0
Let's say there's libmagic installed in /opt/csw/lib, and there's no libmagic
in /usr/lib. Let's suppose you run this:
ctypes.cdll.LoadLibrary('libmagic.so.1')
The OpenCSW Python will successfully load libmagic.so.1. But without the patch,
find_library will not find libmagic.so.1, it will fail to translate 'magic' to
'libmagic.so.1', even though the libmagic.so symlink is present in /opt/csw/lib.
For the patch, the RPATH of the library itself doesn't matter, the important
one is the RPATH of the Python executable itself, which influences what
_ctypes.dlopen() does when looking for a library.
I could write a test by providing providing a sample /usr/ccs/bin/dump output
and mocking out some libraries. Would that be good?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19317
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: -- versions: +Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
New submission from Maciej Bliziński: On Solaris, when you want to link shared libraries from custom directories, you most often don't modify the system search path, but instead set RPATH in your binaries. For example, OpenCSW packages Python into /opt/csw, and sets Python executable's RPATH to /opt/csw/lib. Therefore, dynamically opening shared libraries will by default look into /opt/csw/lib first, and find_library should do the same. I wrote a sample implementation. -- components: ctypes files: find_library_looks_into_rpath.patch keywords: patch messages: 200593 nosy: automatthias priority: normal severity: normal status: open title: ctypes.util.find_library should examine binary's RPATH on Solaris type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file32255/find_library_looks_into_rpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: Removed file: http://bugs.python.org/file32255/find_library_looks_into_rpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: Added file: http://bugs.python.org/file32256/find_library_looks_into_rpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: Removed file: http://bugs.python.org/file32256/find_library_looks_into_rpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: Added file: http://bugs.python.org/file32257/find_library_looks_into_rpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: Removed file: http://bugs.python.org/file32257/find_library_looks_into_rpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: Added file: http://bugs.python.org/file32259/find_library_looks_into_rpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19317 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18605] 2.7: test_threading hangs on Solaris 9
Maciej Bliziński added the comment: Here's the output. After that output -- it hangs. == CPython 2.7.5 (default, Jul 30 2013, 01:41:03) [GCC 4.6.3] == Solaris-2.9-sun4u-sparc-32bit-ELF big-endian == /home/maciej/src/opencsw/pkg/lang-python/python/branches/python-2.7/work/solaris9-sparc/build-isa-sparcv8/Python-2.7.5/build/test_python_28299 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) test_threading test_acquire_contended (test.test_threading.LockTests) ... ok test_acquire_destroy (test.test_threading.LockTests) ... ok test_acquire_release (test.test_threading.LockTests) ... ok test_constructor (test.test_threading.LockTests) ... ok test_different_thread (test.test_threading.LockTests) ... ok test_reacquire (test.test_threading.LockTests) ... ok test_thread_leak (test.test_threading.LockTests) ... ok test_try_acquire (test.test_threading.LockTests) ... ok test_try_acquire_contended (test.test_threading.LockTests) ... ok test_with (test.test_threading.LockTests) ... ok test__is_owned (test.test_threading.RLockTests) ... ok test_acquire_contended (test.test_threading.RLockTests) ... ok test_acquire_destroy (test.test_threading.RLockTests) ... ok test_acquire_release (test.test_threading.RLockTests) ... ok test_constructor (test.test_threading.RLockTests) ... ok test_different_thread (test.test_threading.RLockTests) ... ok test_reacquire (test.test_threading.RLockTests) ... ok test_release_unacquired (test.test_threading.RLockTests) ... ok test_thread_leak (test.test_threading.RLockTests) ... ok test_try_acquire (test.test_threading.RLockTests) ... ok test_try_acquire_contended (test.test_threading.RLockTests) ... ok test_with (test.test_threading.RLockTests) ... ok test_is_set (test.test_threading.EventTests) ... ok test_notify (test.test_threading.EventTests) ... ok test_timeout (test.test_threading.EventTests) ... ok test__is_owned (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_destroy (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_release (test.test_threading.ConditionAsRLockTests) ... ok test_constructor (test.test_threading.ConditionAsRLockTests) ... ok test_different_thread (test.test_threading.ConditionAsRLockTests) ... ok test_reacquire (test.test_threading.ConditionAsRLockTests) ... ok test_release_unacquired (test.test_threading.ConditionAsRLockTests) ... ok test_thread_leak (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok test_with (test.test_threading.ConditionAsRLockTests) ... ok test_acquire (test.test_threading.ConditionTests) ... ok test_notify (test.test_threading.ConditionTests) ... ok test_timeout (test.test_threading.ConditionTests) ... ok test_unacquired_notify (test.test_threading.ConditionTests) ... ok test_unacquired_wait (test.test_threading.ConditionTests) ... ok test_acquire (test.test_threading.SemaphoreTests) ... ok test_acquire_contended (test.test_threading.SemaphoreTests) ... ok test_acquire_destroy (test.test_threading.SemaphoreTests) ... ok test_constructor (test.test_threading.SemaphoreTests) ... ok test_default_value (test.test_threading.SemaphoreTests) ... ok test_release_unacquired (test.test_threading.SemaphoreTests) ... ok test_try_acquire (test.test_threading.SemaphoreTests) ... ok test_try_acquire_contended (test.test_threading.SemaphoreTests) ... ok test_with (test.test_threading.SemaphoreTests) ... ok test_acquire (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_destroy (test.test_threading.BoundedSemaphoreTests) ... ok test_constructor (test.test_threading.BoundedSemaphoreTests) ... ok test_default_value (test.test_threading.BoundedSemaphoreTests) ... ok test_recursion_limit (test.test_threading.BoundedSemaphoreTests) ... skipped 'test macosx problem' test_release_unacquired (test.test_threading.BoundedSemaphoreTests) ... ok test_try_acquire (test.test_threading.BoundedSemaphoreTests) ... ok test_try_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok test_with (test.test_threading.BoundedSemaphoreTests) ... ok test_PyThreadState_SetAsyncExc (test.test_threading.ThreadTests) ... started worker thread trying nonsensical thread id waiting for worker thread to get started verifying worker hasn't exited attempting to raise asynch exception in worker waiting for worker to say it caught the exception all OK -- joining worker ok test_dummy_thread_after_fork (test.test_threading.ThreadTests) ... ok test_enumerate_after_join
[issue18605] 2.7: test_threading hangs on Solaris 9
Maciej Bliziński added the comment: Test results for sources pulled from the mercurial repository: they hang in the same place. == CPython 3.4.0a0 (default, Aug 2 2013, 00:38:45) [GCC 4.6.3] == Solaris-2.9-sun4u-sparc-32bit-ELF big-endian == /home/maciej/src/cpython/build/test_python_19419 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_threading test_abort (test.test_threading.BarrierTests) ... ok test_abort_and_reset (test.test_threading.BarrierTests) ... ok test_action (test.test_threading.BarrierTests) ... ok test_barrier (test.test_threading.BarrierTests) ... ok test_barrier_10 (test.test_threading.BarrierTests) ... ok test_default_timeout (test.test_threading.BarrierTests) ... ok test_reset (test.test_threading.BarrierTests) ... ok test_single_thread (test.test_threading.BarrierTests) ... ok test_timeout (test.test_threading.BarrierTests) ... ok test_wait_return (test.test_threading.BarrierTests) ... ok test_acquire (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_destroy (test.test_threading.BoundedSemaphoreTests) ... ok test_acquire_timeout (test.test_threading.BoundedSemaphoreTests) ... ok test_constructor (test.test_threading.BoundedSemaphoreTests) ... ok test_default_value (test.test_threading.BoundedSemaphoreTests) ... ok test_release_unacquired (test.test_threading.BoundedSemaphoreTests) ... ok test_try_acquire (test.test_threading.BoundedSemaphoreTests) ... ok test_try_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok test_with (test.test_threading.BoundedSemaphoreTests) ... ok test__is_owned (test.test_threading.CRLockTests) ... ok test_acquire_contended (test.test_threading.CRLockTests) ... ok test_acquire_destroy (test.test_threading.CRLockTests) ... ok test_acquire_release (test.test_threading.CRLockTests) ... ok test_constructor (test.test_threading.CRLockTests) ... ok test_different_thread (test.test_threading.CRLockTests) ... ok test_reacquire (test.test_threading.CRLockTests) ... ok test_release_save_unacquired (test.test_threading.CRLockTests) ... ok test_release_unacquired (test.test_threading.CRLockTests) ... ok test_repr (test.test_threading.CRLockTests) ... ok test_thread_leak (test.test_threading.CRLockTests) ... ok test_timeout (test.test_threading.CRLockTests) ... ok test_try_acquire (test.test_threading.CRLockTests) ... ok test_try_acquire_contended (test.test_threading.CRLockTests) ... ok test_with (test.test_threading.CRLockTests) ... ok test__is_owned (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_destroy (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_release (test.test_threading.ConditionAsRLockTests) ... ok test_constructor (test.test_threading.ConditionAsRLockTests) ... ok test_different_thread (test.test_threading.ConditionAsRLockTests) ... ok test_reacquire (test.test_threading.ConditionAsRLockTests) ... ok test_release_save_unacquired (test.test_threading.ConditionAsRLockTests) ... ok test_release_unacquired (test.test_threading.ConditionAsRLockTests) ... ok test_repr (test.test_threading.ConditionAsRLockTests) ... ok test_thread_leak (test.test_threading.ConditionAsRLockTests) ... ok test_timeout (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok test_with (test.test_threading.ConditionAsRLockTests) ... ok test_acquire (test.test_threading.ConditionTests) ... ok test_notify (test.test_threading.ConditionTests) ... ok test_timeout (test.test_threading.ConditionTests) ... ok test_unacquired_notify (test.test_threading.ConditionTests) ... ok test_unacquired_wait (test.test_threading.ConditionTests) ... ok test_waitfor (test.test_threading.ConditionTests) ... ok test_waitfor_timeout (test.test_threading.ConditionTests) ... ok test_is_set (test.test_threading.EventTests) ... ok test_notify (test.test_threading.EventTests) ... ok test_set_and_clear (test.test_threading.EventTests) ... ok test_timeout (test.test_threading.EventTests) ... ok test_acquire_contended (test.test_threading.LockTests) ... ok test_acquire_destroy (test.test_threading.LockTests) ... ok test_acquire_release (test.test_threading.LockTests) ... ok test_constructor (test.test_threading.LockTests) ... ok test_different_thread (test.test_threading.LockTests) ... ok test_reacquire (test.test_threading.LockTests) ... ok test_repr (test.test_threading.LockTests) ... ok test_state_after_timeout (test.test_threading.LockTests) ... ok test_thread_leak (test.test_threading.LockTests) ... ok test_timeout (test.test_threading.LockTests) ... ok test_try_acquire
[issue18605] 2.7: test_threading hangs on Solaris 9
New submission from Maciej Bliziński: Python version: 2.7.5 OS: Solaris 9 Architecture: sparc Looks similar to Issue5114 and Issue6643 but both are now closed. It seems specific to Solaris 9, I'm not seeing this issue on Solaris 10. The symptom is that test_threading hangs indefinitely (tested overnight) . When running pstack on the process, I'm seeing this: - lwp# 1 / thread# 1 ff3dc734 lwp_park (0, 0, 0) ff3d3c74 s9_lwp_park (0, 0, 0, 1, feed4f48, 18f5a4) + 28 ff3dc698 s9_handler (0, 0, 0, 1, feed4f48, 18f5a4) + 90 ff1dea70 _sema_wait (0, feee66a0, fed6b054, feee6000, 2a298478, d1f20) + 1d4 ff1dec30 sema_wait (81aa8, ff1dec24, 722a5b4b, 1101c, feed4f48, 134d60) + c feed4f48 sem_wait (81aa8, 0, fed6b1ac, 0, 0, 1) + 20 ff050890 PyThread_acquire_lock (81aa8, 1, fed6b214, 2, 0, 1ae778) + 5c ff05524c lock_PyThread_acquire_lock (0, 22030, 0, 13ee40, 16a298, 55150) + 50 fefa779c PyCFunction_Call (1ae788, 22030, 0, ff0d8eb8, 55150, ff0551fc) + e4 ff016b14 PyEval_EvalFrameEx (18f5a0, 0, 0, d4f66, 16a298, 22030) + 5ee8 ff0185d0 PyEval_EvalCodeEx (12c968, 0, 18f5a0, 4, 1, 18f5a4) + 924 ff0168f8 PyEval_EvalFrameEx (1902b8, 0, 1, 1765c0, 16a298, 1b12d0) + 5ccc ff0185d0 PyEval_EvalCodeEx (13f608, 0, 1902b8, 4, 1, 1902bc) + 924 ff0168f8 PyEval_EvalFrameEx (154748, 0, 1, 31f7f, 16a298, 1b1250) + 5ccc ff0185d0 PyEval_EvalCodeEx (10d650, 54a50, 154748, 2203c, 0, 2203c) + 924 fef8e11c function_call (22038, 22030, 1386f0, 2203c, 130730, 22030) + 168 fef604e8 PyObject_Call (130730, 22030, 1386f0, ff0e0340, fef8dfb4, 0) + 60 ff0137dc PyEval_EvalFrameEx (169110, 0, 22030, 10e62d, 16a298, 22030) + 2bb0 ff017478 PyEval_EvalFrameEx (168f80, 0, 169114, 1769fa, 16a298, 16a298) + 684c ff017478 PyEval_EvalFrameEx (176cb0, 0, 168f84, 12a2c0, 16a298, 16a298) + 684c ff0185d0 PyEval_EvalCodeEx (13f410, 176cb4, 176cb0, 13433c, 1, 0) + 924 fef8e040 function_call (1b26f0, 134330, 0, ff1bc000, 1b26f0, 0) + 8c fef604e8 PyObject_Call (1b26f0, 134330, 0, ff0e0340, fef8dfb4, 134320) + 60 fef6e530 instancemethod_call (0, 134330, 0, 0, 1b26f0, 134bd0) + a4 fef604e8 PyObject_Call (c3b48, 22030, 0, ff0e0340, fef6e48c, 0) + 60 ff01051c PyEval_CallObjectWithKeywords (c3b48, 22030, 0, 0, 0, 0) + 68 ff05568c t_bootstrap (63bd0, 0, 0, 0, 16a298, ff0e2804) + 4c ff1e53a4 _lwp_start (0, 0, 0, 0, 0, 0) - lwp# 2 / thread# 2 ff3dc734 lwp_park (0, 0, 0) ff3d3c74 s9_lwp_park (0, 0, 0, 1, b64a0d58, 136818) + 28 ff3dc698 s9_handler (0, 0, 0, 1, b64a0d58, 136818) + 90 ff1dea70 _sema_wait (0, feee66a0, fec6b054, feee6000, 2a298478, d1f20) + 1d4 ff1dec30 sema_wait (8ab00, ff1dec24, 722a5b4b, 1101c, feed4f48, 134d60) + c feed4f48 sem_wait (8ab00, 0, fec6b1ac, 0, 0, 1) + 20 ff050890 PyThread_acquire_lock (8ab00, 1, fec6b214, 2, 0, 1ae610) + 5c ff05524c lock_PyThread_acquire_lock (0, 22030, 0, 13ee40, 156168, 55160) + 50 fefa779c PyCFunction_Call (1ae620, 22030, 0, ff0d8eb8, 55160, ff0551fc) + e4 ff016b14 PyEval_EvalFrameEx (18fe60, 0, 0, d4f66, 156168, 22030) + 5ee8 ff0185d0 PyEval_EvalCodeEx (12c968, 0, 18fe60, 4, 1, 18fe64) + 924 ff0168f8 PyEval_EvalFrameEx (18fce8, 0, 1, 1765c0, 156168, 1b11b0) + 5ccc ff0185d0 PyEval_EvalCodeEx (13f608, 0, 18fce8, 4, 1, 18fcec) + 924 ff0168f8 PyEval_EvalFrameEx (18fb88, 0, 1, 136155, 156168, 1a2930) + 5ccc ff0185d0 PyEval_EvalCodeEx (48b60, 18fb8c, 18fb88, 19d41c, 1, 2203c) + 924 fef8e11c function_call (22038, 19d410, 1b3c00, 2203c, 130370, 22030) + 168 fef604e8 PyObject_Call (130370, 19d410, 1b3c00, ff0e0340, fef8dfb4, 19d400) + 60 ff0137dc PyEval_EvalFrameEx (18fa20, 0, 19d410, 10e62d, 156168, 134950) + 2bb0 ff017478 PyEval_EvalFrameEx (18f890, 0, 18fa24, 1769fa, 156168, 156168) + 684c ff017478 PyEval_EvalFrameEx (18f728, 0, 18f894, 12a2c0, 156168, 156168) + 684c ff0185d0 PyEval_EvalCodeEx (13f410, 18f72c, 18f728, 19d3fc, 1, 0) + 924 fef8e040 function_call (1b26f0, 19d3f0, 0, ff1bc000, 1b26f0, 0) + 8c fef604e8 PyObject_Call (1b26f0, 19d3f0, 0, ff0e0340, fef8dfb4, 19d3e0) + 60 fef6e530 instancemethod_call (0, 19d3f0, 0, 0, 1b26f0, 1b1250) + a4 fef604e8 PyObject_Call (1aeaf8, 22030, 0, ff0e0340, fef6e48c, 0) + 60 ff01051c PyEval_CallObjectWithKeywords (1aeaf8, 22030, 0, 0, 0, 0) + 68 ff05568c t_bootstrap (63c30, 0, 0, 0, 156168, ff0e2804) + 4c ff1e53a4 _lwp_start (0, 0, 0, 0, 0, 0) -- components: Tests messages: 193978 nosy: automatthias priority: normal severity: normal status: open title: 2.7: test_threading hangs on Solaris 9 type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18605 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py
Maciej Bliziński added the comment: Python version: 2.7.5 OS: Solaris 9 I'm still observing this issue (or Issue5114) on Solaris 9. The symptom is that test_threading hangs indefinitely (tested: overnight) and running pstack on the process, I'm seeing: - lwp# 1 / thread# 1 ff3dc734 lwp_park (0, 0, 0) ff3d3c74 s9_lwp_park (0, 0, 0, 1, feed4f48, 18f5a4) + 28 ff3dc698 s9_handler (0, 0, 0, 1, feed4f48, 18f5a4) + 90 ff1dea70 _sema_wait (0, feee66a0, fed6b054, feee6000, 2a298478, d1f20) + 1d4 ff1dec30 sema_wait (81aa8, ff1dec24, 722a5b4b, 1101c, feed4f48, 134d60) + c feed4f48 sem_wait (81aa8, 0, fed6b1ac, 0, 0, 1) + 20 ff050890 PyThread_acquire_lock (81aa8, 1, fed6b214, 2, 0, 1ae778) + 5c ff05524c lock_PyThread_acquire_lock (0, 22030, 0, 13ee40, 16a298, 55150) + 50 fefa779c PyCFunction_Call (1ae788, 22030, 0, ff0d8eb8, 55150, ff0551fc) + e4 ff016b14 PyEval_EvalFrameEx (18f5a0, 0, 0, d4f66, 16a298, 22030) + 5ee8 ff0185d0 PyEval_EvalCodeEx (12c968, 0, 18f5a0, 4, 1, 18f5a4) + 924 ff0168f8 PyEval_EvalFrameEx (1902b8, 0, 1, 1765c0, 16a298, 1b12d0) + 5ccc ff0185d0 PyEval_EvalCodeEx (13f608, 0, 1902b8, 4, 1, 1902bc) + 924 ff0168f8 PyEval_EvalFrameEx (154748, 0, 1, 31f7f, 16a298, 1b1250) + 5ccc ff0185d0 PyEval_EvalCodeEx (10d650, 54a50, 154748, 2203c, 0, 2203c) + 924 fef8e11c function_call (22038, 22030, 1386f0, 2203c, 130730, 22030) + 168 fef604e8 PyObject_Call (130730, 22030, 1386f0, ff0e0340, fef8dfb4, 0) + 60 ff0137dc PyEval_EvalFrameEx (169110, 0, 22030, 10e62d, 16a298, 22030) + 2bb0 ff017478 PyEval_EvalFrameEx (168f80, 0, 169114, 1769fa, 16a298, 16a298) + 684c ff017478 PyEval_EvalFrameEx (176cb0, 0, 168f84, 12a2c0, 16a298, 16a298) + 684c ff0185d0 PyEval_EvalCodeEx (13f410, 176cb4, 176cb0, 13433c, 1, 0) + 924 fef8e040 function_call (1b26f0, 134330, 0, ff1bc000, 1b26f0, 0) + 8c fef604e8 PyObject_Call (1b26f0, 134330, 0, ff0e0340, fef8dfb4, 134320) + 60 fef6e530 instancemethod_call (0, 134330, 0, 0, 1b26f0, 134bd0) + a4 fef604e8 PyObject_Call (c3b48, 22030, 0, ff0e0340, fef6e48c, 0) + 60 ff01051c PyEval_CallObjectWithKeywords (c3b48, 22030, 0, 0, 0, 0) + 68 ff05568c t_bootstrap (63bd0, 0, 0, 0, 16a298, ff0e2804) + 4c ff1e53a4 _lwp_start (0, 0, 0, 0, 0, 0) - lwp# 2 / thread# 2 ff3dc734 lwp_park (0, 0, 0) ff3d3c74 s9_lwp_park (0, 0, 0, 1, b64a0d58, 136818) + 28 ff3dc698 s9_handler (0, 0, 0, 1, b64a0d58, 136818) + 90 ff1dea70 _sema_wait (0, feee66a0, fec6b054, feee6000, 2a298478, d1f20) + 1d4 ff1dec30 sema_wait (8ab00, ff1dec24, 722a5b4b, 1101c, feed4f48, 134d60) + c feed4f48 sem_wait (8ab00, 0, fec6b1ac, 0, 0, 1) + 20 ff050890 PyThread_acquire_lock (8ab00, 1, fec6b214, 2, 0, 1ae610) + 5c ff05524c lock_PyThread_acquire_lock (0, 22030, 0, 13ee40, 156168, 55160) + 50 fefa779c PyCFunction_Call (1ae620, 22030, 0, ff0d8eb8, 55160, ff0551fc) + e4 ff016b14 PyEval_EvalFrameEx (18fe60, 0, 0, d4f66, 156168, 22030) + 5ee8 ff0185d0 PyEval_EvalCodeEx (12c968, 0, 18fe60, 4, 1, 18fe64) + 924 ff0168f8 PyEval_EvalFrameEx (18fce8, 0, 1, 1765c0, 156168, 1b11b0) + 5ccc ff0185d0 PyEval_EvalCodeEx (13f608, 0, 18fce8, 4, 1, 18fcec) + 924 ff0168f8 PyEval_EvalFrameEx (18fb88, 0, 1, 136155, 156168, 1a2930) + 5ccc ff0185d0 PyEval_EvalCodeEx (48b60, 18fb8c, 18fb88, 19d41c, 1, 2203c) + 924 fef8e11c function_call (22038, 19d410, 1b3c00, 2203c, 130370, 22030) + 168 fef604e8 PyObject_Call (130370, 19d410, 1b3c00, ff0e0340, fef8dfb4, 19d400) + 60 ff0137dc PyEval_EvalFrameEx (18fa20, 0, 19d410, 10e62d, 156168, 134950) + 2bb0 ff017478 PyEval_EvalFrameEx (18f890, 0, 18fa24, 1769fa, 156168, 156168) + 684c ff017478 PyEval_EvalFrameEx (18f728, 0, 18f894, 12a2c0, 156168, 156168) + 684c ff0185d0 PyEval_EvalCodeEx (13f410, 18f72c, 18f728, 19d3fc, 1, 0) + 924 fef8e040 function_call (1b26f0, 19d3f0, 0, ff1bc000, 1b26f0, 0) + 8c fef604e8 PyObject_Call (1b26f0, 19d3f0, 0, ff0e0340, fef8dfb4, 19d3e0) + 60 fef6e530 instancemethod_call (0, 19d3f0, 0, 0, 1b26f0, 1b1250) + a4 fef604e8 PyObject_Call (1aeaf8, 22030, 0, ff0e0340, fef6e48c, 0) + 60 ff01051c PyEval_CallObjectWithKeywords (1aeaf8, 22030, 0, 0, 0, 0) + 68 ff05568c t_bootstrap (63c30, 0, 0, 0, 156168, ff0e2804) + 4c ff1e53a4 _lwp_start (0, 0, 0, 0, 0, 0) The problem does not occur on Solaris 10. -- nosy: +automatthias ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6643 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18083] _sysconfigdata.py is installed in an arch-independent directory
New submission from Maciej Bliziński:
_sysconfigdata.py is installed into ${prefix}/lib/pythonX.Y/_sysconfigdata.py
which is an architecture-independent directory, as opposed to a path starting
with e.g. ${libdir}, which is architecture-dependent. But _sysconfigdata.py
contains architecture-dependent information, which breaks some installation,
specifically Solaris multi-arch.
A fix would be to move it to an architecture-dependent directory, but this
probably requires some discussion.
---
Original question on the mailing list:
http://mail.python.org/pipermail/python-list/2013-May/647197.html
I'm looking into creating a 32/64-bit Python (2.x and/or 3.x) package
for Solaris. The specificity of that package is that I need to include
both 32-bit and 64-bit binaries in it. The exact way in which the
32/64 support is done is described at [1].
There currently is a Python package that I maintain, which is 32-bit only[2].
I have made an attempt to build a 64-bit package, and my findings are
that the ${prefix}/lib/pythonX.Y/_sysconfigdata.py file contains
system-specific information. Note that it's not ${libdir}/pythonX.Y -
that would have worked, because I'm specifying different ${libdir}
directories when running the 32-bit and 64-bit builds. The Python
installer specifically uses ${prefix}/lib/pythonX.Y. For the most part
is fine, because most of files in there are not architecture-specific,
and it would be quite good to share them among the 32-bit and 64-bit
binaries at runtime. The problem is that some files differ. I've
described it some more at [3].
Ideally, I'd make _sysconfigdata.py return/set different values
depending on the Python runtime that reads it. Something like:
if we're 64-bit:
set values for the 64-bit platform
else:
set values for the 32-bit platform
It's a similar approach to how we currently handle C header files. See
the 'Development packages' section in [1] for more information.
The problem is that it would involve somewhat intrusive patching of
the Python source code, and in long term that means maintainability
issues.
--
components: Installation
messages: 190225
nosy: automatthias
priority: normal
severity: normal
status: open
title: _sysconfigdata.py is installed in an arch-independent directory
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18083
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1250] Building external modules using Sun Studio 12
Maciej Bliziński maciej.blizin...@gmail.com added the comment: I just hit this issue when trying to build matplotlib. The setup script indeed tries to run the C compiler (/opt/SUNWspro/bin/cc) instead of the C++ compiler (/opt/SUNWspro/bin/CC) and fails. This was with Python 2.6.7. Could the problem be that the UnixCCompiler.executables[compiler_cxx] is defined to cc instead of CC? -- nosy: +automatthias status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13398] _cursesmodule does not build, doesn't find Python.h on Solaris
Maciej Bliziński maciej.blizin...@gmail.com added the comment: It's not only the curses module, other two modules are failing as well, the same way - not finding Python.h. maciej@unstable9s :~/src/opencsw/pkg/lang-python/python/branches/python-3.2 grep ^PY_CPPFLAGS work/solaris9-sparc/build-isa-sparcv8/Python-3.2.2/Makefile PY_CPPFLAGS=-I. -IInclude -I$(srcdir)/Include $(CONFIGURE_CPPFLAGS) $(CPPFLAGS) Perhaps PY_CPPFLAGS does not get included in the compiler invocation? Poking around the Makefile, I find: Modules/_cursesmodule.o: $(srcdir)/Modules/_cursesmodule.c; $(CC) $(CCSHARED) $(CFLAGS) $(CPPFLAGS) -c $(srcdir)/Modules/_cursesmodule.c -o Modules/_cursesmodule.o This line doesn't contain a reference to PY_CPPFLAGS. Perhaps the answer is around line 220 in Modules/makesetup? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13398 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13398] _cursesmodule does not build, doesn't find Python.h on Solaris
Maciej Bliziński maciej.blizin...@gmail.com added the comment: I haven't tried building with GCC, Python has always been built with Sun Studio at OpenCSW. I've got very similar build files for Python 2.6, 2.7, 3.0, and 3.1 -- none of them have this problem, so this is a regression in 3.2. What diff would you like to see? The problem manifests itself with pristine Python sources, no patches are needed to reproduce it. When the modules are built, how normally get the -I flags are set so that the modules can find the Python.h file? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13398 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13398] _cursesmodule missing Python.h on Solaris
New submission from Maciej Bliziński maciej.blizin...@gmail.com: Compilation of Python 3.2.2 fails on Solaris 9 as follows: /opt/SUNWspro/bin/cc -xcode=pic32 -xO3 -m32 -xarch=v8 -I/opt/csw/include -c ./Modules/_cursesmodule.c -o Modules/_cursesmodule.o ./Modules/_cursesmodule.c, line 105: cannot find include file: Python.h ./Modules/_cursesmodule.c, line 117: cannot find include file: py_curses.h ./Modules/_cursesmodule.c, line 130: warning: no explicit type given ./Modules/_cursesmodule.c, line 130: syntax error before or at: attr_t ./Modules/_cursesmodule.c, line 130: warning: old-style declaration or incorrect type for: attr_t ./Modules/_cursesmodule.c, line 139: warning: no explicit type given ./Modules/_cursesmodule.c, line 139: syntax error before or at: * (...) The problem seems to be a missing -I flag for the compiler, pointing at the Include directory in Python sources. -- components: Build messages: 147578 nosy: automatthias priority: normal severity: normal status: open title: _cursesmodule missing Python.h on Solaris type: compile error versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13398 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13398] _cursesmodule does not build, doesn't find Python.h on Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: -- title: _cursesmodule missing Python.h on Solaris - _cursesmodule does not build, doesn't find Python.h on Solaris ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13398 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5289] ctypes.util.find_library does not work under Solaris
Changes by Maciej Bliziński maciej.blizin...@gmail.com: -- nosy: +automatthias ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5289 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
