Matthieu Brucher wrote: > 2010/1/21 Dag Sverre Seljebotn <da...@student.matnat.uio.no>: > >> Matthieu Brucher wrote: >> >>>> try: >>>> import sys >>>> import ctypes >>>> _old_rtld = sys.getdlopenflags() >>>> sys.setdlopenflags(_old_rtld|ctypes.RTLD_GLOBAL) >>>> from numpy.linalg import lapack_lite >>>> finally: >>>> sys.setdlopenflags(_old_rtld) >>>> del sys; del ctypes; del _old_rtld >>>> >>>> >>> This also applies to scipy code that relies on BLAS as well. Lisandra >>> Dalcin gave me a tip that is close to this one some months ago >>> (http://matt.eifelle.com/2008/11/03/i-used-the-latest-mkl-with-numpy-and.../). >>> The best official solution is to statically link against the MKL with >>> Python. >>> >>> >>> >> IIUC, it should be enough to load the .so-s in GLOBAL mode once. So it >> is probably enough to ensure NumPy is patched in a way so that SciPy >> loads NumPy which loads the .so-s in GLOBAL mode, so that a seperate >> patch for SciPy is not necesarry. (Remains to be tried, I'm moving on to >> building SciPy now.) >> > > Indeed, it should be enough. > > >> As for static linking, do you mean linking MKL into the Python >> interpreter itself? Or statically linking with NumPy? >> > > statically linking with numpy. This is what was advised to me by Intel. > Somehow I didn't manage to do that.
a) search_static_first does not seem to work for me b) moving the .so's out of the way does manage something, but mkl_lapack only exists in .so form. Moving only that back in still didn't work. In the end I stopped playing, even more as RTLD_GLOBAL seems a superior solution, even if Intel isn't willing to directly support it... Dag Sverre _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
