Hi, we're currently building our own shared object library in Linux (let's call it 'my_library.so' for convenience). We're using BLAS and LAPACK routines from within our my_library.so 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 my_library.so routines (which then make MKL calls) from a stand-alone binary; however, when we call the same my_library.so 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 my_library.so) 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 my_library.so) 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 my_library.so 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 my_library.so 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?
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.