On Mon, Jun 20, 2011 at 4:20 PM, Bruce Southey <bsout...@gmail.com> wrote:
> ** > On 06/19/2011 05:21 AM, Ralf Gommers wrote: > > > > On Tue, Jun 14, 2011 at 5:28 AM, Bruce Southey <bsout...@gmail.com> wrote: > >> On Mon, Jun 13, 2011 at 8:31 PM, Pauli Virtanen <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 >> > 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 >> >> 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 > listNumPy-Discussion@scipy.orghttp://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.) > > You could just have tested that branch, it should have the same issue. To test on 1.6.x, you can just checkout 1.6.x and cherry-pick the relevant commit. I've done that for you at https://github.com/rgommers/numpy/tree/sharedlib-ext-1.6.x For completeness, this is how you grab it: $ git remote add rgommers https://github.com/rgommers/numpy.git $ git fetch rgommers $ git co rgommers/sharedlib-ext-1.6.x Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
