After building a release solution of my Fortran code using Visual Studio community 2019 and OneAPI HPC package, I tried to run the compiled executable outside of Visual Studio and I encountered 3 errors regarding missing libifcoremd.dll, libmmd.dll, and svml_dispmd.dll.
I searched online about this and there were some suggestions to add the .dll's path to the compiler, but I am not sure how to do it in VS2019 since all the posts I saw were for older versions. I never had this issue when I used Parallel Studio before. Following one post, I copied the .dll files to the running directory and the error instead becomes "The application was unable to start correctly (0xc000007b). Click OK to close the application."
I looked under Tools -> Options -> Projects and Solutions but didn't see any option regarding linking paths. I see there is a "command line" option under project properties -> Fortran/Linker. But I am not sure how to include the .dll's path here. Can someone help me out?
I may have found the problem... Originally, Visual Studio would put the release and debug builds and related files directly in the folder. I.e. project/release, and project/debug. But now as I am compiling in x64, it is putting them in project/x64/release and project/x64/debug.
I noticed this when I tried to clean the project but all the files are still there.
However, another project that was compiled in x86, where the release and debug folders are not under x64 still has the issue. So perhaps another thing I did to fix it may have helped:
I was looking around in the One API folder and found a sys_check.bat and it gave me the following error among other messages:
: debugger -- latest
" Error: Environment variable pointing to INTELGTDEBUGGERROOT folder not set."
" The Visual Studio Integration plugin for the debugger will not work."
" Run the script env\vars.bat to fix this configuration problem."
So I found the file under debugger\env\vars.bat and ran it. The above error is no longer there and now everything works, if compiled under x64. The code compiled with x86 still doesn't. But I am not concerned right now.
Thanks for everything!
Thanks for the response! I installed that and now it doesn't say missing dll anymore, but it still says "The application was unable to start correctly (0xc000007b). Click OK to close the application."
I guess copying the dll files to the directory did solve the problem, except now I have another problem.
Try going to The latest supported Visual C++ downloads (microsoft.com) , download and install the Visual Studio 2019 runtime for x64 and also the one for x86.
Those were already installed. I first tried to use the "repair" option for both. I still get the same error. Then I tried to uninstall both and re-install both. The problem persists. Thanks for the help so far, are there anything else I can try?
To clarify, I made sure to re-build the solution each time.
What I suggest is to download Dependency Walker , run it, open your executable. Wait for it to finish analyzing, click File > Save. Save the .dwi file somewhere. Put it in a ZIP file and attach to a reply here so that we can look at it. Be sure to choose the correct download (32-bit or 64-bit) for your application. Don't be concerned by errors it reports - many of them are false - but the rest of the info will be useful.
Ah, this is a Debug build. You can run this only from within Visual Studio or an Intel Fortran Command Line Build environment. (Start > Intel oneAPI 2021 > Intel oneAPI Command Prompt for x86.
Thanks for checking it out.
I am not sure if I mixed up the builds. But I made sure this is the release build this time. If it still says debug, that could be where I need to look at in settings.
Nevertheless, even when I try to run the program through the command Prompt, it still gives the same error.
Are you using Visual Studio 2015? Your program is linked to its libraries - perhaps there's something explicit in your project that does that. Install the x86 (32-bit) package from Download Microsoft Visual C++ 2015 Redistributable Update 3 RC from Official Microsoft Download Cent...
To follow up on this thread. I have installed Microsoft Visual C++ 2015 - 2019 Redistributable from https://visualstudio.microsoft.com/downloads/. It installed it on my computer, I restarted the PC as requested, and recompiled the program, but I still cannot get it to work. I put the program compiled in release into the dependency program, and the results are attached.
If you can take a look and let me know what I can do that would be greatly appreciated!
Some information: my computer currently has a whole lot of redistributables: 2005, various updates of 2008, 2010, various updates of 2012, various updates of 2013, and 14.29.30037 of 2015-2019 x64, and 14.28.29914 of 2015-2019 x86.
Should I consider uninstall all these, as well as visual studio and one-API and reinstall everything?
Initially, I had the DLL errors. When I put the missing DLL directly into the directory where the executable is, I get the error above. Then I installed the various libraries and didn't have to put the DLLs directly in the running folder, and I still get the error above. Last time you mentioned you saw the program is linked to Visual Studio 2015, which I said I shouldn't be using 2015 but 2019 with oneAPI for Fortran.
Additionally, the program runs fine if I run it in Visual Studio. But when I take the compiled executable outside, it does this.
I have an update. A colleague of mine who did not uninstall her Parallel Studio 2019 Update 5 does not have this issue. Her parallel studio is still expired, but it seems that something parallel studio installs but oneAPI doesn't can solve the issue.
The problem is - I cannot reinstall parallel studio because I don't have a valid license anymore.
The .dwi you attached still showed the VS2015 MSVCR140.DLL being used. There were also a bunch of other DLLs referenced with names I did not recognize.
Sorry for coming back to this question sporadically as I have to also focus on completing my research work.
I was just thinking about how the executable can run successfully inside Visual Studio but cannot outside of it. Is it ridiculous to think that VS knows the correct link to the libraries and needed runtimes but when compiling, there is a setting missing somewhere for the compiler and so the compiled code doesn't know after being compiled? If so, where can I go to look at VS's linking paths for compiling a code and running a code inside VS? If I can compare the two files, perhaps I can correct it.
What happens is that VS adds the directories containing debug DLLs to PATH when starting the process to run under the debugger. The compiler isn't involved in this. The idea is that you run a debug build under control of the debugger (you can also run without debugging in VS.) If you want to run outside the VS environment, build a Release configuration (or choose non-debug libraries in the property for that.)
The debug DLLs are not in the same system directory the release DLLs are.
I could build debug and release versions of the code and run them inside VS. Before, I could also run both builds outside the VS, and now I can't run either outside. So I am a bit confused about if I am not compiling the right release build following your response?