[Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1
Tue Jun 21 15:05:26 CDT 2011
On Tue, Jun 21, 2011 at 4:38 PM, Bruce Southey <firstname.lastname@example.org> wrote:
> On 06/21/2011 01:01 AM, Ralf Gommers wrote:
> On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey <email@example.com> wrote:
>> On Mon, Jun 20, 2011 at 2:43 PM, Ralf Gommers
>> <firstname.lastname@example.org> wrote:
>> > On Mon, Jun 20, 2011 at 8:50 PM, Bruce Southey <email@example.com>
>> >> 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
>> >> using git from 'https://github.com/rgommers/numpy.git'. Numpy is
>> >> 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
>> > 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
>> >> >>> 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
>> > I removed the line in ctypeslib that was trying this, so I think you are
>> > 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
>> >> 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
>> >>> get_shared_lib_extension(False)
>> first so_ext .cpython-32mu.so
>> returned so_ext .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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion