Maintaining 15+ year old software package, MKL issue support

[mascenzi]

Hello, 

I've taken over an older software package my company wants to add some functionality to. We don't have funds or time to update all aspects of it, so as is, with new modules is the goal. 

I have two interesting situations. 

Running Windows 10

1) The software package runs perfectly fine, with the exception that once it gets to an MKL call it just aborts the entire program. All aspects of the software works, up until a single button press that calls its first MKL call. Now this package is running an older version of the MKL, from 2010 I believe. 

2) So attempting to update the MKl, I installed the latest release. I integrated it into Visual studio 2019, selected "Sequential" use of the intel MKL and finally rebuilt the package. Now when I run the application it runs just fine. I hit the button that previously would abort the program and it operates fine. Now, here is the issue. It runs fine only when I run it within the IDE. If I run the executable directly, outside of the IDE, then it shuts down at the same place it does in the first situation. 

setup

1) in this situation I have the following configuration to reference the MKL

• Environmental variable PATH pointing to where the follow dll's are located
  • mkl_core
  • mkl_intel_thread
  • mkl_sequential
• visual studio configuration
  • C/C++
    • General
      • Additional Libraries
        • pointing at the \mkl\include directory
  • Linker
    • General
      • Additional Libraries
        • point at the \mkl\lib\intel64 directory
      • Additional Dependencies
        • mkl_intel_lp64_dll.lib
        • mkl_intel_thread_dll.lib
        • mkl_core_dll.lib

2) In this second situation, I have all of the above. I attempted to peel away those settings but it fails to compile without them. Only difference is

• configuration Properties
  • Intel Performance Library
    • Use Intel MKL                 Sequential

I know this is probably very limited information, but I've been banging my head against a wall for some time now. 

[mecej4 · Accepted solution]

From what you have described, I suspect that one or more of your MKL calls are incorrect, or that you have more than one version of MKL installed and the wrong versions of the MKL DLLs are being used when you run your application outside Visual Studio. 

Examine the PATH environment variable. Copy its value into a text file, zip that file and the build-log file from the build that produced the EXE, and attach the file to your reply.

It is possible that correcting PATH is all that is required to fix the problems. If not, you will need to construct a "reduced working example" -- a bug reproducer -- and provide it along with any needed include files, data files and instructions to build and run.

[mascenzi]

mecej4,

Hi, Thanks so much for reaching out. So to keep it simple, you were spot on. Even through I had tried working with the environmental variables several times, as what was occurring sounding very much like it was an environmental variables issue. But how it was resolved is making me scratch my head just as much.Just by dumb luck I fumbled across the fact that itt wasn't a single environmental variable that it needed, in fact it required two. The strange part is that it wanted the same environmental variable twice. Well, there was a slight difference. 

S:\IntelSWTools\compilers_and_libraries_2017\windows\redist\intel64_win\mkl

S:\IntelSWTools\compilers_and_libraries_2017.4.210\windows\redist\intel64_win\mkl

Won't work if either of those are the only one in the system env variables. But both everything works. Why? No idea, maybe you will have one. But as far as I can tell, "\mkl" as part of the 2017 path is nothing more than a shortcut to the 2017.4.210 path.It would obviously make sense if one directory was missing something the other had, but again shortcut. 

Again thanks for the support. 

Michael

mecej4 wrote:

From what you have described, I suspect that one or more of your MKL calls are incorrect, or that you have more than one version of MKL installed and the wrong versions of the MKL DLLs are being used when you run your application outside Visual Studio. 

Examine the PATH environment variable. Copy its value into a text file, zip that file and the build-log file from the build that produced the EXE, and attach the file to your reply.

It is possible that correcting PATH is all that is required to fix the problems. If not, you will need to construct a "reduced working example" -- a bug reproducer -- and provide it along with any needed include files, data files and instructions to build and run.

[mecej4]

There are two parts of a typical MKL installation: (i) a development part and (ii) a runtime part. The development part contains include files, Fortran modules and libraries, and batch files. The runtime part contains the MKL DLLs for three architectures (IA32, LP64, ILP64).

The Parallel Studio installer does a good job of setting up the batch files so that the environment is correctly configured, but sometimes end users customize the installation (I do frequently) and some things may get corrupted.

When you build an EXE that uses MKL, and it is not running properly, it may be useful to analyze the EXE using the Windows Dependency Walker tool (see http://www.dependencywalker.com ) or the Cygwin/Linux tool ldd.exe.

The Intel Parallel Studio installations create directories of which some are symbolic links. Some older tools may have problems with such directories. Here is what I have for IFort 2018 (trimmed a bit):

 Directory of c:\lang\PS2018

10/21/2018  12:16 PM    <SYMLINKD>     compilers_and_libraries 
10/21/2018  12:16 PM    <DIR>          compilers_and_libraries_2018
10/07/2018  06:50 AM    <DIR>          compilers_and_libraries_2018.3.210
10/21/2018  12:17 PM    <DIR>          compilers_and_libraries_2018.5.274

Depending on which choices you made while installing, you may have only the latest version or some new and some old, and the features installed may be different between (in my case) Update 3 and Update 5. Usually, the installation tools keep one update from being mixed into another. However, if some of the startup batch files were customized by the end user, problems may sometimes occur.