I’m trying to use the MKL with some programs and libraries, but I encountered something really strange and I’m not alone.
First, what is i_free ? Accoding to Intel, it’s their way to handle memory allocation and deallocation. They are only pointers to the actual memory functions so as to let the user decide if he wants a custom memory handler. Since 10.0.3, Intel changed their model, and the trouble begins.

Now, if you want to load the MKL on the fly, you can’t. The problem is that a lot of scientific programs work that way:

• Matlab,
• Python (Numpy, Scipy, …),
• almost every other scientific IDE, closed source or not.

What is happening? I don’t know exactly. Just try this. Create a bogus library with the following code:

#include <mkl_dfti.h>
extern "C"
{
extern void small test()
{
  DFTI_DESCRIPTOR_HANDLE hdl;
 
  DftiCreateDescriptor(&hdl, DFTI_DOUBLE, DFTI_COMPLEX, 1, 1024);
  DftiCommitDescriptor(hdl);
}
}

Compile it with:

g++ -o lib.os -c -fPIC lib.cpp
g++ -o libtest.so -shared lib.os -lmkl -lguide -liomp5 -lpthread

Now, try this small Python script (save it as test.py for example):

import numpy.ctypeslib as c
import os
 
lib = c.load_library("libtest.so", os.path.dirname(__file__))
lib.small_test()

With MKL <= 10.0.2, it should work fine. With MKL 10.0.3, it will crash with a "MKL FATAL ERROR" saying that i_free is not defined in libmkl_def.so. If you link the library to a program, it works like a charm.

This function is actually defined in libmkl_core.so. I’ve asked Intel Support a solution to this problem, as I really link against this library as it is defined in libmkl.so (a text file). Their answer was that I should first load libmkl_core.so before libmkl_def.so. As I really don’t know how I could bypass what the system does, I asked them a more precise solution. 3 weeks latter, I’m still waiting for an answer…

I’ve tried everything: link order, loading by hand both libraries to see what happens, … nothing helped.

If you think this is a critical bug in the MKL, please file a bug (the MKL is free for non commercial use, and gives access to Intel Premier Support where you can file a bug). If you think that the MKL is awesome, please file a bug so that everyone can use this fantastic library.

If someone has a clue, I’m all ears.
If/when Intel gives me an update, I’ll post it.

Update:
Lisandro Dalcín gave me a tip to solve the issue. It adds a flag to the dlopen() function Python uses when loading a module.

Just add the following code:

import sys
import ctypes
 
flags = sys.getdlopenflags()
sys.setdlopenflags(flags|ctypes.RTDL_GLOBAL)
import module #import here your module
sys.setdlopenflags(flags)

If your module needs additional modules (like Numpy for f2py wrapped modules or SWIG wrapped modules that call import_array()), import them before setting the dlopen flags.

It does not solve the issue with Numpy or Matlab, but it’s a start.

Update 2:
The Intel Support told me that the MKL dynamic libraries should not be linked to another shared library. So the static libraries must be used in order to use the MKL correctly.