[issue19317] ctypes.util.find_library should examine binary's RPATH on Solaris
Richard PALO added the comment: [fingers not yet warmed up] that is '/opt/local/lib/libmagic.so' -- ___ 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
Richard PALO added the comment:
An example:
richard@omnis:/home/richard$ python2.7
Python 2.7.11 (default, Apr 27 2016, 04:35:25)
[GCC 4.9.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> from ctypes.util import find_library
>>> find_library('magic')
>>> cdll.LoadLibrary('libmagic.so')
Finally, as you can see above, LoadLibrary() works fine to load
'/opt/local/libmagic.so' because of the runpath in the python binary, but
find_library() does not because the runpath is ignored.
This should probably be considered as 'unexpected' behaviour.
--
___
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
Richard PALO added the comment: oups... I meant to add the comment about $ORIGIN (not really useful here) but also the fact that the binary python is built with the dependencies found via the library path (-L, for example) and the eventual run-paths (-R or -runpath) when not in the system paths. As indicated by automatthias@, package managers such as pkgsrc, CSW, *ports and the like have their $PREFIX off of the system main path.. usually in /usr/pkg, /usr/local, /opt/local or something like that (for unices and linux sort of systems, anyway). My pkgsrc python2.7 binary has the following runpath: ``` richard@omnis:/home/richard$ dump -Lpv /opt/local/bin/python2.7 |grep RPATH [12]RPATH /opt/pbulk32/gcc49/i486-sun-solaris2.11/lib/.:/opt/pbulk32/gcc49/lib/.:/opt/local/lib ``` What is being requested greatly simplifies things, and can probably be generalised to other ELF based systems too. BTW I came across the issue as well with py-magic. -- ___ 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
Richard PALO added the comment: There *is* a feature with linking called $ORIGIN. -- ___ 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
[issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2
Richard PALO added the comment: curiously enough, I was able to test with python3.5. The same errors result, and the same workaround seems to get over it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2
Richard PALO added the comment: This turns out to be related to the locale environment set to 'C'. A UTF-8 locale seems to get over the issue. A fellow pkgsrc colleague filed an issue with lxml already relating to that fact for the test suite (https://bugs.launchpad.net/lxml/+bug/1522052) cheers -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2
Richard PALO added the comment:
I notice similar problems, as found when running the test suite for lxml 3.5.0
on python2.7
==
ERROR: test_etree_parse_io_error (lxml.tests.test_io.ETreeIOTestCase)
--
Traceback (most recent call last):
File "/opt/local/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File
"/tmp/pkgsrc/textproc/py-lxml/work/lxml-3.5.0/src/lxml/tests/test_io.py", line
276, in test_etree_parse_io_error
dn = tempfile.mkdtemp(prefix=dirnameRU)
File "/opt/local/lib/python2.7/tempfile.py", line 339, in mkdtemp
_os.mkdir(file, 0700)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 40-53:
ordinal not in range(128)
==
ERROR: test_etree_parse_io_error (lxml.tests.test_io.ElementTreeIOTestCase)
--
Traceback (most recent call last):
File "/opt/local/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File
"/tmp/pkgsrc/textproc/py-lxml/work/lxml-3.5.0/src/lxml/tests/test_io.py", line
276, in test_etree_parse_io_error
dn = tempfile.mkdtemp(prefix=dirnameRU)
File "/opt/local/lib/python2.7/tempfile.py", line 339, in mkdtemp
_os.mkdir(file, 0700)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 40-53:
ordinal not in range(128)
the code snippet is in test_io.py", line 276
266 def test_etree_parse_io_error(self):
267 # this is a directory name that contains characters beyond
latin-1
268 dirnameEN = _str('Directory')
269 dirnameRU = _str('КÐ\260Ñ\032Ð\260Ð\273Ð\276Ð\263')
270 filename = _str('nosuchfile.xml')
271 dn = tempfile.mkdtemp(prefix=dirnameEN)
272 try:
273 self.assertRaises(IOError, self.etree.parse,
os.path.join(dn, filename))
274 finally:
275 os.rmdir(dn)
276 dn = tempfile.mkdtemp(prefix=dirnameRU)
277 try:
278 self.assertRaises(IOError, self.etree.parse,
os.path.join(dn, filename))
279 finally:
280 os.rmdir(dn)
even if I change dirnameRU to a simple French 'Répertoire' I still get errors...
It is not an option to upgrade to 3.0, sorry.
BTW, I tried passing dirnameRU.encode('utf-8') but that just generates
a different error:
ERROR: test_etree_parse_io_error (lxml.tests.test_io.ETreeIOTestCase)
--
Traceback (most recent call last):
File "/opt/local/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File
"/tmp/pkgsrc/textproc/py-lxml/work/lxml-3.5.0/src/lxml/tests/test_io.py", line
278, in test_etree_parse_io_error
self.assertRaises(IOError, self.etree.parse, os.path.join(dn, filename))
File "/opt/local/lib/python2.7/posixpath.py", line 73, in join
path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 40:
ordinal not in range(128)
--
nosy: +risto3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23315>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2
Richard PALO added the comment:
If I also add .encode('utf-8') to filename on line 278, that seems gets over
the pathname problem.
I guess it comes down to the fact that if sys.filesystemencoding() is utf-8,
which in my case it is (on SunOS), I believe these conversion should be
automatic.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23315>
___
___
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
Richard PALO added the comment: I tried this patch out on pkgsrc, it does seem reasonable and appropriate. So +1 from me. It does only look for libraries the actual $PREFIX directory used by packaging systems such as pkgsrc and csw. (typically /usr/local, /opt/local or /opt/csw in the case of csw) So for completeness, perhaps consideration should be made some time for cases such as when environment variables like LD_LIBRARY_PATH*, LD_CONFIG* et cetera are used... BTW, LD_LIBRARY_PATH is also used on other ELF platforms. -- nosy: +risto3 ___ 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
[issue19561] request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined
New submission from Richard PALO: I'd like to have reopened this previous issue as it is still very much the case. I believe as well that the common distros (I can easily verify OpenIndiana and OmniOS) patch it out (patch file attached). Upstream/oracle/userland-gate seems to as well. It is time to retire this check, or at least take into consideration the parametrization from unistd.h: #if defined(_XPG4_2) extern int gethostname(char *, size_t); #elif !defined(__XOPEN_OR_POSIX) || defined(__EXTENSIONS__) extern int gethostname(char *, int); #endif -- components: Build files: Python26-10-gethostname.patch keywords: patch messages: 202690 nosy: risto3 priority: normal severity: normal status: open title: request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined type: compile error versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file32584/Python26-10-gethostname.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19561] request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined
Richard PALO added the comment: I don't believe the problem is a question solely of building the python sources, but also certain dependent application sources... I know of at least libreoffice building against python and this problem has come up. The workaround was to apply the patch indicated (here, on python3.3). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19561] request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined
Richard PALO added the comment: Sure, attached is a simple test found on the internet, compiled with the following reproduces the problem: richard@devzone:~/src$ /opt/local/gcc48/bin/g++ -o tp tp.cpp -DSOLARIS -I/opt/local/include/python2.7 -L/opt/local/lib -lpython2.7 In file included from /opt/local/include/python2.7/Python.h:58:0, from tp.cpp:1: /opt/local/include/python2.7/pyport.h:645:35: error: declaration of C function 'int gethostname(char*, int)' conflicts with extern int gethostname(char *, int); ^ In file included from /opt/local/include/python2.7/Python.h:44:0, from tp.cpp:1: /usr/include/unistd.h:351:12: error: previous declaration 'int gethostname(char*, uint_t)' here extern int gethostname(char *, size_t); -- Added file: http://bugs.python.org/file32592/tp.cpp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
