On Tue, Jun 21, 2011 at 4:38 PM, Bruce Southey <bsout...@gmail.com> wrote:
> ** > On 06/21/2011 01:01 AM, Ralf Gommers wrote: > > > > On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey <bsout...@gmail.com> wrote: > >> On Mon, Jun 20, 2011 at 2:43 PM, Ralf Gommers >> <ralf.gomm...@googlemail.com> wrote: >> > >> > >> > On Mon, Jun 20, 2011 at 8:50 PM, Bruce Southey <bsout...@gmail.com> >> wrote: >> >> >> >> I copied the files but that just moves the problem. So that patch is >> >> incorrect. >> >> >> >> I get the same errors on Fedora 15 supplied Python3.2 for numpy 1.6.0 >> and >> >> using git from 'https://github.com/rgommers/numpy.git'. Numpy is >> getting >> >> Fedora supplied Atlas (1.5.1 does not). >> >> >> >> It appears that there is a misunderstanding of the PEP because 'SO' and >> >> 'SOABI' do exactly what the PEP says on my systems: >> > >> > It doesn't on OS X. But that's not even the issue. As I explained >> before, >> > the issue is that get_config_var('SO') is used to determine the >> extension of >> > system libraries (such as liblapack.so) and python-related ones (such as >> > multiarray.cpython-32m.so). And the current functions don't do >> mindreading. >> >> >> >> >>> from distutils import sysconfig sysconfig.get_config_var('SO') >> >> '.cpython-32m.so' >> >> >>> sysconfig.get_config_var('SOABI') >> >> 'cpython-32m' >> >> >> >> Consequently, the name, 'multiarray.pyd', created within numpy is >> invalid. >> > >> > I removed the line in ctypeslib that was trying this, so I think you are >> not >> > testing my patch. >> > >> > Ralf >> > >> >> >> >> Looking the code, I see this line which makes no sense given that the >> >> second part is true under Linux: >> >> >> >> if (not is_python_ext) and 'SOABI' in >> >> distutils.sysconfig.get_config_vars(): >> >> >> >> So I think the 'get_shared_lib_extension' function is wrong and >> probably >> >> unneeded. >> >> >> >> >> >> Bruce >> >> >> >> Just to show that this is the new version, I added two print >> statements in the 'get_shared_lib_extension' function: >> >>> from numpy.distutils.misc_util import get_shared_lib_extension >> >>> get_shared_lib_extension(True) >> first so_ext .cpython-32mu.so >> returned so_ext .cpython-32mu.so >> '.cpython-32mu.so' >> >>> get_shared_lib_extension(False) >> first so_ext .cpython-32mu.so >> returned so_ext .so >> '.so' >> > > This all looks correct. Before you were saying you were still getting > 'multiarray.pyd', now your error says 'multiarray.so'. So now you are > testing the right thing. Test test_basic2() in test_ctypeslib was fixed, but > I forgot to fix it in two other places. I updated both my branches on > github, please try again. > >> >> The reason for the same location is obvious because all the patch does >> is move the code to get the extension into that function. So the >> 'get_shared_lib_extension' function returns the extension '.so' to the >> load_library function. However that name is wrong under Linux as it >> has to be 'multiarray.cpython-32mu.so' and hence the error in the same >> location. I did come across this thread >> 'http://bugs.python.org/issue10262' which indicates why Linux is >> different by default. >> >> So what is the actual name of the multiarray shared library with the Mac? >> If it is ' 'multiarray.so' then the correct name is "libname + >> sysconfig.get_config_var('SO')" as I previously indicated. >> >> It is, and yes that's correct. Orthogonal to the actual issue though. > > Ralf > > > > > While the test now pass, you have now changed an API for load_library. > Only in a backwards-compatible way, which should be fine. I added a keyword, the default of which does the same as before. The only thing I did other than that was remove tries with clearly invalid extensions, like ".pyd" on Linux. Now that I'm writing that though, I think it's better to try both ".so" and ".cpython-32mu.so" by default for python >=3.2. > This is not something that is meant to occur in a bug-fix release as well > as the new argument is undocumented. But I do not understand the need for > this extra complexity when "libname + sysconfig.get_config_var('SO')" works > on Linux, Windows and Mac. > > I've tried to explain this twice already. You have both " multiarray.cpython-32mu.so" and "liblapack.so" (or some other library like that) on your system. The extension of both is needed, and always obtained via get_config_var('SO'). See the problem? If someone knows a better way to do this, I'm all for it. But I don't see a simpler way. Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
