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/i
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
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
Richard PALO added the comment:
There *is* a feature with linking called $ORIGIN.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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/i
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
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
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
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
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
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
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
12 matches
Mail list logo
