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

[Dag Sverre Seljebotn]

Matthieu Brucher wrote:
> 2010/1/21 Dag Sverre Seljebotn <dagss@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