Strange problem with libmmd.dll

[gib]

The problem I'm having is the same as one that was raised here in 2013:

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

This error message: "The procedure entry point _libm_sse2_cbrt could not be located in the link library libmmd.dll." is generated when a program is invoked on a particular Win7 computer.  It doesn't occur on any of the four Win7 machines that I use, nor on the two machines that my collaborator uses, it happens only on his student's computer.  All machines have the same libmmd.dll.  I guessed that on the failing machine another version of lbmmd.dll was being found, but according to Dependency Walker the DLL that I build (that apparently uses libmmd.dll) is finding the file that I installed on that machine.

This is a big mystery, and it is creating a problem for this student who must submit his PhD dissertation in 3 months.  A secondary mystery is why libmmd.dll is being used, which I believe means that libmmd.lib is being linked.  I have two programs that do very similar things.  One needs libmmd.dll, the other doesn't, and I don't understand the difference.

I am still using IVF 11.075, which has always been completely satisfactory for my purposes.

Thanks

Gib

[Lorri_M_Intel]

There are two ways to link your program; statically or dynamically.

If the program is looking for libmmd.dll then it was linked dynamically.    My guess on your secondary mystery is that one of your programs is linked dynamically, the other statically.

OK, now to the problem at hand.   When Windows goes to run a program that has dynamic libraries, it looks for those libraries in a particular order.  I copied the following from an MSDN website:

1. The directory where the executable module for the current process is located.

2. The current directory.

3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.

4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.

5. The directories listed in the PATH environment variable.

My guess is that the student's computer has another libmmd.dll on it, that is getting "hijacked" when he/she tries to run your program.   Have that person do a full search for libmmd.dll; it might be enlightening.   It's possible that there's an older redistributable on that system than you or your colleagues have. 

                            --Lorri

[Steve_Lionel]

On the student's system run DependencyWalker and do a File > Save As to save a .dwi file. Attach a zip of that here so we can see. Does Dependency Walker also complain about the missing entry point? It's best to open a command prompt window, CD to the folder with the EXE in question, and run DependencyWalker from there just to make sure that the environment matches.

[gib]

Lorri, in both programs the linking is the same.  I don't know what libmmd.dll does, but I can't see why it's needed by one but not the other program.

I copied libmmd.dll to the directory where the .exe lives, and the error went away.  It seems that Dependency Walker is not telling the truth.  Obviously there is another older copy of libmmd.dll somewhere that is being found.  Presumably this means that some other installed software was build with Fortran - am I right in thinking that libmmd.dll is Fortran-specific? 

Currently the DLL directory is at the end of the PATH, I've asked for it to be moved to the start, at which time I expect that libmmd.dll will be able to be put back to where it was.

Steve, the program .exe is invoked by double-clicking in Explorer (most students today haven't even heard of the command line), and hitherto DW has always seemed reliable when executed in the same way.  When I am next at the location of that computer I'll test your suggestion of invoking DW at the command line.  Why would DW complain about the missing entry point, since it thinks the program is using the correct DLL?

Many thanks to you both.

Gib

[Steve_Lionel]

If a bad DLL was in the same folder as the EXE, then DW might not pick it up. But I would like to see the .dwi.

[gib]

There was no DLL in the same folder as the EXE until I copied the correct DLL there, fixing the problem.

[Lorri_M_Intel]

libmmd.dll has the math library entry points, and it is also shipped with the Intel C/C++ kit.

[Steve_Lionel]

That copying the "correct DLL" there tells me that the "incorrect DLL: is elsewhere on the system and is being picked up.

[gib]

Yes, I concluded that another DLL was being found.  That libmmd.dll is also shipped with the Intel C/C++ kit provides a possible reason - it's much more likely that other software on this computer was built with C/C++ than was built with Fortran.  I'm surprised that DW gave the wrong answer, and will investigate further when the opportunity arises.  Meanwhile shifting the program's DLL directory to the front of the PATH should have the desired effect.

[Steve_Lionel]

If a reasonably current version of Intel C++ was on the system, that the DLL came with that should not be a problem. Or one could install the current compiler redistributables package.

[gib]

Steve, this is a biomedical student who wouldn't know a compiler if it bit him on the backside.  I'm guessing that he has some software, presumably quite old, that was built (not by me) with an Intel compiler.  I'll report back here when I track it down.

[Steve_Lionel]

You could always use a search tool such as AgentRansack to search the system for all copies of libmmd.dll. (Windows search probably won't find it.)

[GVautier]

Hello

dir c:\libmmd.dll /S

will find all occurences.

[gib]

Using dir I see that there are many instances of libmmd.dll connected with Adobe software, but these are all more recent (2013 - 2015) than the version I have (2009) that came with IVF 11.075.  There are two older than this:

 Directory of C:\Program Files\IBM\SPSS\Statistics\23

12/03/2008  08:02 p.m.         2,923,520 libmmd.dll

and

 Directory of C:\Windows\SysWOW64

03/11/2006  06:15 p.m.         2,809,948 libmmd.dll

The latter is very surprising.  Is it possible that Windows uses libmmd.dll, or is it more likely that some misguided person put the DLL there?  I don't see it on my two W7 machines.

Edit: Not so fast: http://originaldll.com/file/libmmd.dll/16972.html

Probably it was put there to amend a deficiency in an Adobe installation.  Maybe the safest option would be to replace that file with a recent version.

[mecej4]

Gib, DLLs and EXEs in SysWOW64 are 32-bit versions, and can coexist on a PC with 64-bit DLLs and EXEs of the same name. When a package is installed on a PC running a 64-bit version of Windows, the installer will place such files in System32 or SysWOW64, as appropriate.

Under Windows-x64, putting a 64-bit item into SysWOW64 or putting a 32-bit item into System32 serves no purpose and can cause havoc, so please note this.

Under Windows-x86, SysWOW64 will not be present, so such confusion is not possible.

[gib]

Hi mecej4, all I would consider doing is replacing the old libmmd.dll there (which is being found by my program and giving an error) with a more recent version of the same DLL.

[mecej4]

Gib, my point was that it is not sufficient to look at the name and dates of creation or modification of a DLL; you have to check its "bitness". See, for example, https://www.raymond.cc/blog/determine-application-compiled-32-64-bit/ .

The Cygwin file utility gives the following information for the two versions of libmmd.dll that came with Ifort 17.0.7, both of which are tagged with the same date.

...\compilers_and_libraries_2017.7.272\windows\redist\intel64\compiler>file libmmd.dll
libmmd.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows

...\compilers_and_libraries_2017.7.272\windows\redist\ia32\compiler>file libmmd.dll
libmmd.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

[gib]

OK, I understand.  I didn't know that there could be two versions of libmmd.dll.  My version of ifort is 32-bit, and I have only 32-bit versions of the DLL, one in ...\bin\ia32, the other in ...\lib\ia32.

[mecej4]

If your development PC is running 32-bit Windows, note that you will not be able to upgrade to Ifort 17.0 and later -- see https://software.intel.com/en-us/articles/intel-visual-fortran-compiler-170-for-windows-release-notes-for-intel-parallel-studio-xe#sysreq . These newer releases require a 64-bit Windows version on the host on which compilation is performed, even if the target is 32-bit Windows.

[gib]

My OS is 64-bit, but in any case I have no plans to upgrade, since ifort 11.0 does everything I need (unless I can get somebody else to pay for it.)