Missing symbol 'for_realloc_lhs' in Matlab's libifcorem​d.dll'

Question

I built a toto.dll and a toto.lib with ifort (Intel's 2017 update 4 fortran compiler). Then I used mex matlab's compiler to produce several mexw64 files.

When I used mex I linked to toto.lib. Then, I ran a .m file (matlab file) inside matlab 2017a 64bits (under win10 64bits), an this file is using functions from the various mexw64's I compiled.

In the matlab file, at the first call of such function I got the following error :

Invalid MEX-file 'C:\path\to\mexfile.mexw64': Missing symbol 'for_realloc_lhs'
in 'C:\Program Files\MATLAB\R2017a/bin/win64\libifcoremd.dll' required by 'C:\path\to\mexfile.mexw64'.

My fortran compiler is intel fortran 2017 update 4.

I found this :

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/726858

but it does not help that much as for me :

• replacing the matlab dll by the intel fortran is not a viable (nor correct) solution (it hides the real problem)
• asking mathworks yielded no answer so far ... (hence my post here)

Can't I somehow tell to matlab to look for the libifcoremd.dll' in the intel fortran directory first, instead of looking in the matlab directory ? (I tried addpath inside the .m file, without success.) What should I do ?

Answer 1

I have met with similar issue. I have compiled the DLL from Intel Fortran Compiler, and called it from MatLab. But when running in MatLab, it complained that missing symbol 'for_realloc_lhs'. The solution is to change the compiling option in Intel Fortran compiling setting from menu "project-->Fortran-->Libraries-->Runtime Library-->Multithreaded". default option is Multithread DLL(/libs;dll/threads). The idea is to change the dynamic dll linking during runtime to static dll.

Hope this will be helpful for you.

Answer 2

If Matlab includes libifcoremd.dll in the same folder as the Matlab executable, which is a horrible thing for them to do, you can't override it. My advice would be to delete the Intel compiler DLLs from that location, though they will likely return on an update.

If they're in a separate folder named on PATH, make sure that the Intel folder is first on PATH.

Probably the best approach for you is to build your DLL to be linked against the static libraries (Fortran > Libraries > Use Run-Time Library > Multithreaded (/MT)). Then you won't be at the mercy of Matlab's bad behavior. I recommend this only when the caller of your DLL is not Fortran.