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

Dag Sverre Seljebotn dagss@student.matnat.uio...
Thu Jan 21 05:57:09 CST 2010


(Apologies if this has been fixed in trunk; I base this on 1.4.0 and no 
related comments of MKL on the mailing list)

I finally got the latest version of MKL working. What appears to have 
changed is that the MKL shared libraries will themselves dynamically 
load different other libraries, depending on the detected CPU.

This is in some ways great news for me, because it means I can avoid 
worrying about miscompiles when compiling one single version of 
NumPy/SciPy to use for our heterogenous cluster. So I'd rather *not* 
link statically [1].

Anyway, after modifying site.cfg [2], things almost work, but not quite. 
The problem is that Python by default imports shared libs using 
RTLD_LOCAL. With this patch to NumPy it does:

Change in numpy/linalg/linalg.py:

from numpy.linalg import lapack_lite

to:

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

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).
c) Should this only be enabled by a flag somewhere? Where? Or can one 
just do it regardless of BLAS?
d) Do I need a "if hasattr" for Windows, or will Windows just ignore it, 
or does this apply to Windows too?

[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*.

Dag Sverre


More information about the NumPy-Discussion mailing list