On Tue, Jun 21, 2011 at 10:05 PM, Ralf Gommers
<ralf.gomm...@googlemail.com>wrote:
>
>
> 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:
>>
>>
>>> 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 should try both extensions:
https://github.com/rgommers/numpy/tree/sharedlibext
Does that look better?
Ralf
>
>
>> 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
