I've distributed a program with a DLL compiled using IVF 10.1. It runs fine on my PC, but not on the client's. 'Dependency Viewer' indicated that we needed
LIBMMDD -- Intel
LIBMMD -- Intel
LIBIFCOREMDD -- Intel
Plan9FOS -- Support file from me
MSVCR80D -- Microsoft
DFORRT -- used by Plan9FOS
and all these files are reported as being present in \Windows\System32.
But still the DLL is reported as failing to be found.
When I recompiled with DVF the DLL worked, so it appears to be that there is either a missing dependency, or one of the IVF files (or MSVCR80D) cannot just be copied, it needs registration.
My work-around at the moment is to re-issue using DVF, but I would like to move to IVF.
What suggestions are there for possible missing dependencies or incorrect installation assumptions?
The client's PC runs on XP. I can duplicate the problem on a PC that does not IVF as a development environment installed.
Thanks.
Jeremy
LIBMMDD -- Intel
LIBMMD -- Intel
LIBIFCOREMDD -- Intel
Plan9FOS -- Support file from me
MSVCR80D -- Microsoft
DFORRT -- used by Plan9FOS
and all these files are reported as being present in \Windows\System32.
But still the DLL is reported as failing to be found.
When I recompiled with DVF the DLL worked, so it appears to be that there is either a missing dependency, or one of the IVF files (or MSVCR80D) cannot just be copied, it needs registration.
My work-around at the moment is to re-issue using DVF, but I would like to move to IVF.
What suggestions are there for possible missing dependencies or incorrect installation assumptions?
The client's PC runs on XP. I can duplicate the problem on a PC that does not IVF as a development environment installed.
Thanks.
Jeremy
連結已複製
10 回應
Quoting - dudley@wrcplc.co.uk
I've distributed a program with a DLL compiled using IVF 10.1. It runs fine on my PC, but not on the client's. 'Dependency Viewer' indicated that we needed
LIBMMDD -- Intel
LIBMMD -- Intel
LIBIFCOREMDD -- Intel
Plan9FOS -- Support file from me
MSVCR80D -- Microsoft
DFORRT -- used by Plan9FOS
and all these files are reported as being present in WindowsSystem32.
But still the DLL is reported as failing to be found.
When I recompiled with DVF the DLL worked, so it appears to be that there is either a missing dependency, or one of the IVF files (or MSVCR80D) cannot just be copied, it needs registration.
My work-around at the moment is to re-issue using DVF, but I would like to move to IVF.
What suggestions are there for possible missing dependencies or incorrect installation assumptions?
The client's PC runs on XP. I can duplicate the problem on a PC that does not IVF as a development environment installed.
Thanks.
Jeremy
LIBMMDD -- Intel
LIBMMD -- Intel
LIBIFCOREMDD -- Intel
Plan9FOS -- Support file from me
MSVCR80D -- Microsoft
DFORRT -- used by Plan9FOS
and all these files are reported as being present in WindowsSystem32.
But still the DLL is reported as failing to be found.
When I recompiled with DVF the DLL worked, so it appears to be that there is either a missing dependency, or one of the IVF files (or MSVCR80D) cannot just be copied, it needs registration.
My work-around at the moment is to re-issue using DVF, but I would like to move to IVF.
What suggestions are there for possible missing dependencies or incorrect installation assumptions?
The client's PC runs on XP. I can duplicate the problem on a PC that does not IVF as a development environment installed.
Thanks.
Jeremy
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
Les
Quoting - Les Neilson
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
Les
I didn't realise I couldn't send over a debug version. I'll try a release version.
Hopefully that will resolve the problem.
Quoting - dudley@wrcplc.co.uk
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.
I didn't realise I couldn't send over a debug version. I'll try a release version.
Hopefully that will resolve the problem.
List of Re-distributable files with the Intel Fortran Compiler for Windows:
libmmd.dll
libmmdd.dll
libifcoremd.dll
libifcorert.dll
I note that the release DLL appears to have NO IVF dependencies ...
Quoting - bendel boy
Edited contents of fredist.txt
List of Re-distributable files with the Intel Fortran Compiler for Windows:
libmmd.dll
libmmdd.dll
libifcoremd.dll
libifcorert.dll
I note that the release DLL appears to have NO IVF dependencies ...
List of Re-distributable files with the Intel 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
Quoting - David White
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):
Quoting - Steve Lionel (Intel)
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.
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.
Quoting - Steve Lionel (Intel)
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.
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.
