On 06/19/2011 05:21 AM, Ralf Gommers wrote:
On Tue, Jun 14, 2011 at 5:28 AM, Bruce Southey <bsout...@gmail.com
<mailto:bsout...@gmail.com>> wrote:
On Mon, Jun 13, 2011 at 8:31 PM, Pauli Virtanen <p...@iki.fi
<mailto:p...@iki.fi>> wrote:
> On Mon, 13 Jun 2011 11:08:18 -0500, Bruce Southey wrote:
> [clip]
>> OSError:
>>
/usr/local/lib/python3.2/site-packages/numpy/core/multiarray.pyd:
cannot
>> open shared object file: No such file or directory
>
> I think that's a result of Python 3.2 changing the extension module
> file naming scheme (IIRC to a versioned one).
>
> The '.pyd' ending and its Unix counterpart are IIRC hardcoded to the
> failing test, or some support code in Numpy. Clearly, they
should instead
> ask Python how it names the extensions modules. This information
may be
> available somewhere in the `sys` module.
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org>
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
Pauli,
I am impressed yet again!
It really saved a lot of time to understand the reason.
A quick comparison between Python versions:
Python2.7: multiarray.so
Python3.2: multiarray.cpython-32m.so
<http://multiarray.cpython-32m.so>
Search for the extension leads to PEP 3149
http://www.python.org/dev/peps/pep-3149/
That looked familiar:
http://projects.scipy.org/numpy/ticket/1749
https://github.com/numpy/numpy/commit/ee0831a8
This is POSIX only which excludes windows. I tracked it down to the
list 'libname_ext' defined in file "numpy/ctypeslib.py" line 100:
libname_ext = ['%s.so' % libname, '%s.pyd' % libname]
On my 64-bit Linux system, I get the following results:
$ python2.4 -c "from distutils import sysconfig; print
sysconfig.get_config_var('SO')"
.so
$ python2.5 -c "from distutils import sysconfig; print
sysconfig.get_config_var('SO')"
.so
$ python2.7 -c "from distutils import sysconfig; print
sysconfig.get_config_var('SO')"
.so
$ python3.1 -c "from distutils import sysconfig;
print(sysconfig.get_config_var('SO'))"
.so
$ python3.2 -c "from distutils import sysconfig;
print(sysconfig.get_config_var('SO'))"
.cpython-32m.so
My Windows 32-bit Python2.6 install:
>>> from distutils import sysconfig
>>> sysconfig.get_config_var('SO')
'.pyd'
Making the bug assumption that other OSes including 32-bit and 64-bit
versions also provide the correct suffix, this suggest adding the
import and modification as:
import from distutils import sysconfig
libname_ext = ['%s%s' % (libname, sysconfig.get_config_var('SO'))]
Actually if that works for Mac, Sun etc. then 'load_library' function
could be smaller.
The issue is that libraries built as Python extensions have the extra
".cpython-mu32", but other libraries on your system don't. And
sysconfig.get_config_var('SO') is used for both. I don't see another
config var that allows to distinguish between the two. Unless on
platforms where it matters there are separate return values in
sysconfig.get_config_vars('SO'). What do you get for that on Linux?
The logic of figuring out the right extension string should not be
duplicated, distutils.misc_util seems like a good place for it. Can
you test if this works for you:
https://github.com/rgommers/numpy/tree/sharedlib-ext
Finally the test_basic2 in "tests/test_ctypeslib.py" needs to be
changed as well because it is no longer correct. Just commenting out
the 'fix' appears to work.
It works in the case of trying to load multiarray, but the function
under test would still be broken.
Ralf
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Okay,
So how do I get these changes and apply them to the release candidate?
(This part of the development/test workflow needs some attention.)
Bruce
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
