I have a problem running a fortran program on other computers that the compilation was not performed on when I used Visual Studio. This problem, nevertheless, does not occur when I compiled and linked the same program using command lines below.
In my program, I've made use of a graphic library "Dislin" and had set up project properties per attached file "Visual Studio with dislin settings" to make it work.
On the command line option, I used these commands to compile and link (exa_f90.f90 is my program):
ifort -Ic:\dislin\ifc -c exa_f90.f90
C:\dislin\examples> link exa_f90.obj -subsystem:console c:\dislin\disifl.lib gdi32.lib user32.lib
I've searched this problem in the fortran compiler forum and found that a solution may be to use Multithread Lib instead of Multithread DLL Lib. However in my case, I've got a bunch of errors when trying to use the Multithread Lib (attached file for another program but with the same library) although the Multithread DLL Lib worked OK.
Another question is: How do I keep a template with settings shown in "Visual Studio with dislin settings" without having to reset each setting when I start a new program that uses the same settings?
I am using the following:
OS: Windows 10
Visual Studio version Community 2019 16.11.3
Fortran compiler Classic 2021.3.0
I am a beginner of Intel Fortran Compiler.
- VVit 100821
Well firstly in VS solution explorer if you select "properties" of the right mouse click menu for your project it will pop the properties page. under the fortran tab>command line entry you can see the command lien VS is usinging for compile. There is a similar one for the linker on the linker tab.
Secondly if you run a command line build create a cmd window using the Windows menu shortcut for your compiler install, you need to pick the 32 or 64 one. This will set a cmd window with all the paths and environment that the compiler and linker need.
According to Microsoft experts, this problem occurs due to corrupt registry settings, or system issues due to virus infection or third-party tool installations. Installation of third-party software can change the default configuration for running EXE files, which often leads to failures when you try to run EXE files.
On the system(s) without Intel Development tools installed you need to install the Intel Redistributables for the development tools. These include the necessary DLL's (or .so's on Linux) that are required to run built programs. The installation of the Redistributables also sets up the necessary environment variables to use these DLL's.
While linking with static libraries can (may) resolve this issue, it is not practical in all cases, to wit OpenMP is supported only as a DLL.
Thank you Jim.
I've tried installing the redistributables as you'd suggested (ifort_redist_ia32 & intel64).
However, I'm still getting 2 errors "VCRUNTIME140D.dll" and "ucrtbased.dll" not found.
This is somehow an improvement as I'd previously got 4 errors ("libifcoremdd.dll" & "libmmdd.dll" not found, in addition to the two).
This suggests that you have done a Debug configuration build. Debug builds are not usable outside the compiler build environment. Rebuild the DLL as a Release configuration.
You may also need the Visual C++ runtime installed as well. Get that from Latest supported Visual C++ Redistributable downloads | Microsoft Docs
Thank you Steve,
I've tried using "Multithread DLL (/libs:dll /threads)" instead of "Debug Multithread DLL (/libs:dll /threads /dbglibs)" per your suggestion and got a bunch of errors due to unrecognized functions/routines, etc. Then, I've also installed the Visual C++ based on your 2nd suggestion and gone back to the Debug library. The resulting built worked as before but with the previous issue (exe cannot be run on other computers).
I'd think the solution may be how to set VS to be the same as the command line because the command line works without any problems.
As in my original post "On the command line option, I used these commands to compile and link (exa_f90.f90 is my program):
ifort -Ic:\dislin\ifc -c exa_f90.f90
C:\dislin\examples> link exa_f90.obj -subsystem:console c:\dislin\disifl.lib gdi32.lib user32.lib"
You are linking to a separately built library (DISLIN) that was built as a Debug configuration. Unlike Intel Fortran, MS or Intel C++ makes different external references depending on whether you have specified debug libraries or not. If your Fortran and C++ settings for this are not consistent, you'll get what we dubbed "Mixed C Library Syndrome".
It is also possible that the DISLIN library was built to link to the static C++ libraries. The solution is to go back to the beginning, rebuild DISLIN with the same Release configuration settings as you use for Fortran.
There are different flavours of DISLIN. You need to be careful in making sure you picked the correct flavour for your computer set up. it is a pain, but you may have to just keep trying - sooner or later you will STUMBLE on the correct combination for your machine.
Did you get the correct DISLIN for your version of windows.
I'd gone through the process you've mentioned. I assumed that I've got that solved (at least partially) as the program (using Dislin) is running using the command line method. The problem is only that the program cannot be run on a different computer if I build it in VS (it's working properly when linking in a command line). It seems to me that my current problem is from VS settings.
I've used "ifort -c dislin.f90" as a command line to compile the dislin source file.
In order to do what you've suggested in the 2nd paragraph, I understand that this should be differently defined to be consistent, correct?
Could you please let me know what command line should be?
Also, is there a way to keep a template with settings without having to reset each setting when I start a new program that uses the same settings?
Thanks for your help,