[Numpy-discussion] Proposed fix for MKL and dynamic loading

[Dag Sverre Seljebotn]

David Cournapeau wrote:
> Dag Sverre Seljebotn wrote:
>
>   
>> Questions:
>>
>> a) Should I submit a patch?
>> b) Negative consequences? Perhaps another Python module can now not load 
>> a different BLAS implementation? (That still seems better than not being 
>> able to use MKL IMO).
>>     
>
> Besides the problem of ctypes not always being available, I am very wary 
> of those library-specific hacks. Worse, it is version dependent, because 
> it depends on the MKL.
>   
I was thinking that this was perhaps a general problem -- that *if* 
ATLAS started implementing support for dynamically switchable kernels at 
load time (which is a feature I certainly wish for), it would suffer the 
same problems. But I don't really know that.

DLFCN can be used instead of ctypes. Which I think is not always 
available either, but "except ImportError: pass" should be fine in this 
kind of situation -- if you need the workaround you'd typically have it.

The only real issue I can see is if it has a significant impact on 
import times for non-MKL users.

But I won't put up a big fight for this kind patch -- I can work around 
it for my own purposes. I just though it might be nice to make things 
easier/more transparent for NumPy/MKL users.
>> [1] BTW, I could not figure out how to link statically if I wanted -- is 
>> "search_static_first = 1" supposed to work? Perhaps MKL will insist on 
>> loading some parts dynamically even then *shrug*.
>>     
>
> search_static_first is inherently fragile - using the linker to do this 
> is much better (with -WL,-Bshared/-Wl,-Bstatic flags).
>   

Thanks! (I'll do that if I get any problems, but I have 3-4 other libs 
depending on BLAS as well loaded, so shared is better in principle.)

Dag Sverre