[Numpy-discussion] Proposed fix for MKL and dynamic loading
Dag Sverre Seljebotn
Fri Jan 22 03:34:07 CST 2010
David Cournapeau wrote:
> Dag Sverre Seljebotn wrote:
>> 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.
>>  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.)
More information about the NumPy-Discussion