Intel® Software Network

Those look like debug libraries to me. Try sending a release version.

The names LIBMMDD and LIBIFCOREMDD indicate that you are distributing DEBUG versions of your exe/dll.
You may only distribute RELEASE versions (libmmd, libifcoremd etc)

The file fredist.txt in the <install-dir>/license folder lists the Intel compiler libraries that are redistributable.

Les

OK.

I didn't realise I couldn't send over a debug version. I'll try a release version.

Hopefully that will resolve the problem.

Edited contents of fredist.txt

List of Re-distributable files with the Intel(R) Fortran Compiler for Windows:

libmmd.dll
libmmdd.dll
libifcoremd.dll
libifcorert.dll

I note that the release DLL appears to have NO IVF dependencies ...

If you link your DLL with static libraries (Multithreaded option -> uses switches /libs:static /threads), then you should be able to distribute your DLL without these libraries.  I previously had similar problems to you, but now do not distribute any secondary DLL's to my customers.

Regards,

David

I have the same problem as well, with the dependency of my DLL on LIBIFCOREMD.DLL and LIBMMD.DLL that I would prefer not to have to redistribute.

I tried compiling the DLL with /libs:static in the Linker > CommandLine > Additional options (in the Release version) but Dependency Walker still reports the dependency on the IVF libraries above.

Any idea why this is happening? Any switches that may interfere with this? Help would be greatly appreciated!

I paste below my project settings (for IVF11+VS2008):

<Configuration Name="Release|Win32" ConfigurationType="typeDynamicLibrary">
<Tool Name="VFFortranCompilerTool" SuppressStartupBanner="true" AdditionalIncludeDirectories="..\..\XXX" AlternateParameterSyntax="false" LocalVariableStorage="localStorageAutomatic" InitLocalVarToNAN="true" FloatingPointExceptionHandling="fpe0" IEEEMinusZero="true" RuntimeLibrary="rtMultiThreadedDLL"/>
<Tool Name="VFLinkerTool" AdditionalOptions="/libs:static" SuppressStartupBanner="true" SubSystem="subSystemWindows" LinkDLL="true"/>
<Tool Name="VFResourceCompilerTool"/>
<Tool Name="VFMidlTool" SuppressStartupBanner="true"/>
<Tool Name="VFCustomBuildTool"/>
<Tool Name="VFPreLinkEventTool"/>
<Tool Name="VFPreBuildEventTool"/>
<Tool Name="VFPostBuildEventTool" CommandLine="copy $(OutDir)\$(ProjectName).dll &quot;..\YYY&quot; /y"/>
<Tool Name="VFManifestTool" SuppressStartupBanner="true"/></Configuration></Configurations>

You did not set the option correctly.  /libs:static is a compiler option, not a linker option.  Set it as Fortran > Libraries > Use Run-Time Library > Multithreaded

Thanks Steve! I got confused because an earlier post said "If you link your DLL with static libraries (Multithreaded option -> uses switches /libs:static /threads),".

Does this mean my original /libs:static in the linker settings just gets ignored? Would it not be more informative to return a warning that an invalid switch was attempted?

Also - is there an equivalent option under CVF to statically link the DLL against other DLLs?

Incidentally, now when I check the dependencies I see the warning that "DWMAPI.dll" is missing. I googled it and it seems to be a common "problem" that isnt a problem if this DLL is never actually called.

Do you not get something like this in the build output?

1>LINK : warning LNK4044: unrecognized option '/libs:static'; ignored

The option in CVF is the same and is pretty much in the same place in the project options.

Ignore the DWMAPI.dll thing.

My apologies - The Link warning was indeed issued but I missed it.

I also got the CVF static DLL linking working - thanks for that! I do still find comparing results on CVF vs IVF to frequently find coding (and ocasionally compiler) errors.