I'm trying to link Fortran code with Matlab using the Mex function. I can successfully compile and link the code using the following instruction:
mex COMPFLAGS="$COMPFLAGS -Qopenmp -Qmkl"... '-IC:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.5.267\windows\mkl\include'... '-LC:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.5.267\windows\mkl\lib\intel64'... ero_dep_fortran.F Module.F prepare_bank_collapse.F LINEAR_ELASTIC_STIFFNESS.F FAILURE_CRITERION.F OUTPUT.F pardisonew.F
However, when I execute the generated .mexw64 function, Matlab crashes without any error information. Then I debug my Fortran code line by line, and I found that Matlab crashes when invoking the function pardiso which comes from Intel MKL library. It seems that when invoking function from MKL, Matlab will crash and I have no idea how to fix it.
I also try to run the code on the Intel Parallel Studio XE 2017 compiler using makefile as:
ifort Module.F OUTPUT.F FAILURE_CRITERION.F pardisonew.F LINEAR_ELASTIC_STIFFNESS.F prepare_bank_collapse.F ero_dep_fortran.F /Qopenmp /Qmkl /nostandard-realloc-lhs /MD -o BANK_COLLAPSE.exe
The generated .exe works. So the problem is not due to the code self or the function pardiso from Intel MKL library. Maybe there are some conflicts between Matlab mkl and intel mkl?
I use Matlab 2019b and Intel Parallel Studio XE 2017 for Fortran with Microsoft Visual Studio 2015 to compile and link the code.
I use windows 10 system and the version of compiler and library is 2017.5.267
Any suggestions will be appreciated.
This is the question to the Mathlab support forum. MKL is used as a backend from MatLab. Mathlab uses several domains from MKL, including BLAS, LAPACK, Pardiso and some other. You may check the version of MKL which is used by this current version of Mathlab by calling "version -blas" command line, for example. Could you check? it seems Matlab 2019b uses MKL 2018.
ok, thanks for keeping us updated. Actually combining ILP64 and LP64 mode will produce the segfault and this is the expected behavior. if you originally added all details, we were able to resolve this issue here.