Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
6427 Discussions

Intel MKL Static Link with MATLAB MEX File Problem


Hi, we're currently building our own shared object library in Linux (let's call it '' for convenience).  We're using BLAS and LAPACK routines from within our file, and are statically linking the Intel MKL (2020.0.1) using the compiler & linker options as recommended by the Intel MKL Link Line Advisor.  Everything works fine when we call our routines (which then  make MKL calls) from a stand-alone binary; however, when we call the same routines from a MATLAB MEX file, the MKL is somehow calling into the MKL .so files included with MATLAB.  We verified this by two methods:

1. By calling 'mkl_get_version()': from the standalone binary (via a wrapper call in returns 'Intel(R) Math Kernel Library Version 2020.0.1 Product Build 20200208 for Intel(R) 64 architecture applications' and from the MATLAB MEX file (via the same wrapper call in the same returns 'Intel(R) Math Kernel Library Version 2019.0.3 Product Build 20190125 for Intel(R) 64 architecture applications'.  Again, this is using the exact same file for both the standalone binary and the MEX file.

2. By examining the stack trace when the MEX file crashes in an MKL routine.  This is showing the call stack going into MATLAB's MKL .so file.  The crashes are likely occurring because MATLAB is using ILP64 and we're using LP64.

Statically linking the MKL when building should prevent Linux's loader from attempting to load any MKL-related .so files, and no  MKL .so files show up in ldd output.  The only way I can imagine this scenario occurring is if the MKL is using dlopen() or something similar to determine if there's already an MKL instance loaded into memory, and then using it.  Is there any way to stop this behavior?

0 Kudos
3 Replies

Update: this is apparently an issue with the linker arguments,  not an MKL issue.  It's probably compounded by MATLAB possibly using LD_PRELOAD, which is affecting our .so file.


we only could comment that MKL doesn't check if there's already an MKL instance loaded into memory and we even don't validate/tested such an option.


This issue has been resolved and we will no longer respond to this thread. If you require additional assistance from Intel, please start a new thread. Any further interaction in this thread will be considered community only.