I have this fortran code compiling fine ( intel compiler 18.0.0033.14) on a win server r12, and running just fine ONLY if launched from within visual studio. If i copy the executable and relative dlls to a folder and run it from there, i get a runtime error: "cannot find entry point for__rtc_uninit_use_src of the procedure within the dll".
the same code used to run fine before the latest windows updates....
What's going on? Could this have anything to do with forbidden access to some files (i'm not administrator on that win machine)?
Which "relative dlls" have you copied to the other folder?
This entry point is in the Intel Fortran runtime library.
Windows finds DLLs by looking in the same directory as the executable, then the current directory, then the Windows and Windows System directories, and finally it looks on PATH.
It is quite likely that you do not have the Intel Fortran library locations on your path.
You can resolve this by running your program from one of the command prompts provided by your Intel Fortran installation, which is the easiest solution.
Otherwise, you will need to make sure that the library directory is on PATH.
Hi Lorri, thanks a lot for your prompt reply!
With "relative dlls" I mean some projects of the solution generate dlls, which need to be in the same directory as the executable.
Running from the intel prompt solves the issue. I've passed this hint to the system administrator.
How can we now make it work from any prompt (as it used to be just a few days ago, before a bunch of win updates had been released)?
I strongly suspect that the responsible is the "use dfport", in which file and folder is this module located in the intel fortran installation?
looking forward to knowing your opinion!
USE DFPORT doesn't affect this; that mod file simply has interface declarations for the portability routines.
I suspect that the Windows OS upgrade modified your PATH variable. I also assume that sometime before the upgrade, an administrator had added the directory location for libifcoremd.dll.
To find that directory on your system, I would go into the command prompt you used above, and issue the command
DIR /S libifcoremd.dll
Then you can have the administrator add one of the directories found to the PATH environment variable.
This should allow you to run your application outside of the Intel Fortran-supplied command prompt
I agree with Lorri that using the DFPORT module doesn't affect DLL searching, but the routines defined in that module are provided by libifportmd.dll, so if that isn't on PATH this problem can occur. However, the entry point in question is in libifcoremd.dll, as Lorri said.
Installing Intel Parallel Studio ads the compiler DLL locations to PATH as part of the redistributables install. I have seen in the past that if PATH gets "too long" (where the actual boundary can vary but is usually around 2048 characters), the path gets truncated and things can go awry. Another problem I would see sometimes is when the user (or installation of some other software package) installed an old version of the compiler DLLs, and if Windows sees these first it can cause this error when a newer entry point is used.
First, I suggest opening a command prompt window where the program doesn't work and doing a:
set path > path.txt
making sure that you have set default (cd) to a writeable folder. Open path.txt in a text editor. The value of PATH should include "C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler"
If it doesn't, I'd suggest installing the compiler redistributables from here.
If that does not solve the problem, then look for other copies of libifcoremd,dll on the system - you may be surprised to find them outside where the Intel installer puts them. I like to use Agent Ransack (a free tool) for this. If you find the Intel compiler DLLs outside the Intel redist folders, delete them (or rename them with an _old suffix or similar.)
Steve nailed it!
after the installation of intel Parallel Studio, a (quite old) version of Flow3d (flowscience) was installed and it uses an older version of the same dll. The problem is that it adds its own path on top of the list, and windows searches the path list in ascending order...
Wouldn't it be wise for windows to jump to the next path if the current one issues an error (of any kind)??
anyway...thanks a lot for the support!
Glad to hear it - this kind of issue can be frustrating. Another useful tool in diagnosing DLL problems is DependencyWalker. You run that, open your EXE, and it can tell you the location of the DLLs it found (though you have to ask for the full path). A problem with DependencyWalker, though, is that on 64-bit systems it doesn't follow Windows rule for skipping "wrong-architecture" DLLs so it will complain about architecture mismatches that don't in fact exist.
Microsoft created the concept of "Side by Side Assemblies" that attempt to address the scourge often called "DLL Hell". Microsoft itself uses these, but Intel and most other vendors do not.