libmmdd.dll libifcoremdd.dll is needed in Deployment

[JHLee1]

I am using ONEAPI BaseKit and HPCKit for Fortran compiler with Visual Studio 2019. It's free.
I made a Fortran program and run with no problem.
But this is only thru Visual Studio Debug.
When I run the exe file from Windows Explorer, outside of Visual Studio, by double click, it requests libmmdd.dll and libifcoremdd.dll.
My purpose is to deploy it to another computer.
Do I miss something in Visual Studio compiler option?

[Steve_Lionel]

Annoyingly, the Intel oneAPI install intentionally omits installing the shared libraries for general use on the system. All previous versions did install these, and I have complained about it to Intel. Worse, there is no warning anywhere that you need to install something else. Go to Intel® oneAPI standalone component installation files , select Runtime Versions > Runtime Versions - Microsoft Windows > Intel Fortran Compiler Classic for Windows. Download and install that.

[JohnNichols]

I want my students to use the Fortran water supply analysis next semester, so do I just need them to install these standalone components on their computer. 

I was thinking instead of using a text file as the input for their names etc, we could build it into a dll and teach them a little Fortran - the water supply program calls the dll. 

Do you think that would work with students?

[JohnNichols]

There are two runtimes for Fortran one classic and one beta, but they are identical -- is that on purpose?

[Barbara_P_Intel]

ifort and ifx share the Fortran Runtime Libraries by design.   

They also share the Fortran Front End.  ifx is lagging in Fortran features for now as the developers put in the LLVM hooks.

[Steve_Lionel]

@JohnNichols , if you want the students to run the Fortran application linked to DLL libraries (the default), they will need to install the standalone runtime package.

[rajt1]

I have the same problem. I have installed <Intel Fortran Compiler Classic for Windows>, but I still get the

"ibifcoremdd.dll is missing from your computer" message. There are several copies of the DLL on my C: drive and it's registered in several places and still I get theis message.

Any suggestions?

[Steve_Lionel]

I am not sure what you mean by "registered" - the location of the DLLs needs to be in the system PATH environment variable. Installing the "Standalone component" kit I linked to above will do what is needed. Yes, the DLL will be present on your computer, but not in a place Windows is looking for it.

[rajt1]

Thanks for your quick response, Steve.

The standalone component kit did not do it. 

There are copies in intelswtools and in system32.

Where is windows looking for it? 

[Steve_Lionel]

Delete the ones in system32 - they don't belong there and will mess things up.

I'd expect to see them somewhere under C:\Program Files (x86)\Common Files\Intel (I'm not on a system with oneAPI installed right now so I don't know the exact path. The Intelswtools copy is from an old install, and those aren't supposed to be in PATH either. 

You might need to log out and in again to get PATH updated - I have seen that sometimes. Otherwise you can manually edit the system PATH to add the path under Common Files.

[DavidWhite]

I note also that these are debug libraries.

The normal Intel licensing permitted installation of runtime libraries on additional machines, except for the debug libraries.  So for installation on another machine, you should normally only distribute "Release" versions of your exe.

To save needing to install the runtime libraries onto another machine, it is useful to use the Multithreaded Runtime library option (/libs:static).  This includes all of the runtime libraries into your exe -- it has the cost of making your exe larger for distribution, but has the safety that all of the required libraries will be available, and that should there be multiple versions on the target machine, your exe will always use the correct one.

[rajt1]

Thanks both.

David: I am using multithreaded libraries - multithread dll crashes. I suspect a conflict with an extended precision (100 integer digits) library I'm using on a number theory problem. As for deploying, I'm deploying only to my multi-processor workstation (developing on my laptop), so I don't think there's a license issue anyway. The program runs fine under Microsoft Visual Studio on both machines, but I need to run multiple copies on the workstation and that's what's failing.

Steve: Intelswtools is not in either system path. The system paths appear to be correct on both machines. After your last post I remembered something from the dark ages - autoexec.bat. There were no Intel paths there, that may be the problem. I shall revise the dos box today and try again.

I wish I had time to study and understand the implications of compiler and linker options better.

Thanks again.

[Steve_Lionel]

intelswtools should NOT be in Path. You should have C:\Program Files (x86)\Common Files\intel\Shared Libraries\intel64 and C:\Program Files (x86)\Common Files\intel\Shared Libraries\ia32 in Path.

autoexec.bat? This isn't DOS anymore.

Right click on This PC, select Properties, Advanced System Settings, Environment Variables. Under System Variables there is Path. The definition will have %INTEL_DEV_REDIST% instead of the expanded path.

[rajt1]

Steve

intelswtools is not in any path. As far as I can tell it's not used by anything, but older versions of libifcoremdd.dll do show up in a search.

C:\Program Files (x86)\Common Files\intel\Shared Libraries\intel64 and C:\Program Files (x86)\Common Files\intel\Shared Libraries\ia32 are both in the system path.

Adding the two paths to the (very old) autoexec.bat in the C: root solved the problem. The program now runs in the command prompt window. I have yet to see if I can run 15 simultaneous programs in command prompt (= dos box as far as I'm concerned) on the workstation.

Thanks again for your help.