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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion