[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 th

[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris

Changes by Maciej Bliziński : -- versions: +Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue19317> ___ ___ Python-bugs-list mailin

[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris

Changes by Maciej Bliziński : Removed file: http://bugs.python.org/file32257/find_library_looks_into_rpath.patch ___ Python tracker <http://bugs.python.org/issue19

[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris

Changes by Maciej Bliziński : Added file: http://bugs.python.org/file32259/find_library_looks_into_rpath.patch ___ Python tracker <http://bugs.python.org/issue19

[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris

Changes by Maciej Bliziński : Added file: http://bugs.python.org/file32257/find_library_looks_into_rpath.patch ___ Python tracker <http://bugs.python.org/issue19

[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris

Changes by Maciej Bliziński : Removed file: http://bugs.python.org/file32256/find_library_looks_into_rpath.patch ___ Python tracker <http://bugs.python.org/issue19

[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris

Changes by Maciej Bliziński : Added file: http://bugs.python.org/file32256/find_library_looks_into_rpath.patch ___ Python tracker <http://bugs.python.org/issue19

[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris

Changes by Maciej Bliziński : Removed file: http://bugs.python.org/file32255/find_library_looks_into_rpath.patch ___ Python tracker <http://bugs.python.org/issue19

[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&#x

[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

[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-

[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 indefin

[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 /

[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

[issue1250] Building external modules using Sun Studio 12

Maciej Bliziński 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

[issue13398] _cursesmodule does not build, doesn't find Python.h on Solaris

Maciej Bliziński 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/Pyth

[issue13398] _cursesmodule does not build, doesn't find Python.h on Solaris

Maciej Bliziński 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 y

[issue13398] _cursesmodule does not build, doesn't find Python.h on Solaris

Changes by Maciej Bliziński : -- title: _cursesmodule missing Python.h on Solaris -> _cursesmodule does not build, doesn't find Python.h on Solaris ___ Python tracker <http://bugs.python.org

[issue13398] _cursesmodule missing Python.h on Solaris

New submission from Maciej Bliziński : 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 in

[issue5289] ctypes.util.find_library does not work under Solaris

Changes by Maciej Bliziński : -- nosy: +automatthias ___ Python tracker <http://bugs.python.org/issue5289> ___ ___ Python-bugs-list mailing list Unsubscribe: