How do I control which compilers/libraries a build might use ?

[WSinc]

See verbose build text I extracted:

Suppose I don't want to use that particular set of libraries - trying to find one that does not have that BUG that no one seems to know how to fix.

Now, if I want to try another library set (not 2016.4.246) how can I do that ?

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Searching libraries
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifcoremt.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifport.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqw_mdi.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqwin.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\user32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comctl32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\gdi32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comdlg32.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libmmt.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\lib\LIBCMTD.lib:
1>      Found __load_config_used
1>        Loaded LIBCMTD.lib(loadcfg.obj)
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libirc.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\svml_dispmt.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\lib\OLDNAMES.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\mkl\lib\ia32\mkl_intel_c.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\mkl\lib\ia32\mkl_sequential.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\mkl\lib\ia32\mkl_core.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\lib\libcpmt.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\kernel32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\ImageHlp.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\uuid.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifcoremt.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifport.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqw_mdi.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqwin.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\user32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comctl32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\gdi32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comdlg32.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libmmt.lib:
1>Finished searching libraries

[mecej4]

gib wrote:
Bill, PathEditor is a very useful tool for editting the PATH:

https://www.softpedia.com/get/System/System-Miscellaneous/Path-Editor.shtml

I have not tried this specific software, but many such utilities edit the Windows-wide user and system paths. What we wish to probe, however, is the effective path that pertains to a specific Fortran program that Bill is running inside Visual Studio. That path is usually an augmentation/adaptation of the system-wide path, and those adaptations, made in configuration and batch files, is wherein the problem is probably situated.

[WSinc]

OK, I will try that Fortran source code.

The problem seems to be :

WHAT PATH IS ACTUALLY BEING USED WHEN i AM TRYING TO RUN MY APPLICATION ?

DOING something before I open the Parallel studio does not seem to be relevant here.

and the problem appears to be the entry points it is getting (OR NOT) when I start execution

(outside of my 2 LINKER PASSES).

BTW, why does it NOT allow me to add any C++ code to my project ? Just curious.

[mecej4]

You can add the lines of code #21 to your own code at its beginning (declarations in their place, executable statements later), or replace "program" by "subroutine" and CALL print_env_var() from within your code.

[WSinc]

OK, here is the environment for the one that FAILS::(see SS14_fails.png)

and the one that WORKS (see SS14_works.png)

See any important differences ?

[WSinc]

Just to reiterate, both of these call DGESV in exactly the same way, with the correct number and type of arguments.

and both of them run the linker to completion without showing any errors.

The one that fails, crashes with that missing entry point.

I had to remove the reference to DGESV in that one, because it wont even execute otherwise.

When I omit the call to DGESV, the missing entry point disappears, and it runs fine.

It appears that both point to the same MKL library as well.

So the problem is what happens at execution time when it does the dynamic link?.

It would be nice to get VERBOSE output from the dynamic link.

[mecej4]

When you report console output, please copy and paste the text as text rather than attaching a screenshot, since that would make it possible to take parts of the text and use those in the response without having to retype lots of text that is read from the screenshot.

Here is the problem, as the details of PATH show:

1. You have remnants of one or more releases of Parallel Studio 2016, including in particular the compiler and MKL redistributables, in the directory c:\Program Files (x86)\IntelSWtools\
2. You have the compiler redistributables of an older version of Parallel Studio, possibly 2013 SP1, installed in C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\. However, this does not include any MKL components.
3. Although we do not see this in the PATH information, I gather that you have and use the 2013 SP1 Fortran compiler. It probably has the matching set of libraries and those 2013 SP1 libraries are used by the linker when you build in Visual Studio. Here is where the mismatch occurs. When you choose to use DLL libraries; the import libraries of the DLLs are for 2013 SP1, but the matching DLLs are not installed. However, the 2016 DLLs are installed, are located in PATH, and an attempt is made to use them; they are lacking some of the entry points that exist in the 2013 import libraries but not in the 2016 DLLs. This fails and gives you the runtime error.

These items confirm what I had suspected (and mentioned) several times. Here are my recommendations to get things working again:

1. If you are not using Parallel Studio 2016, uninstall it completely. At a minimum, remove its components from PATH.
2. Check if you have MKL directories under C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\. If not, you need to install the MKL redistributables that go with with Parallel Studio 2013 SP1. You can find the installer at https://software.intel.com/en-us/articles/intel-compilers-redistributable-libraries-by-version (choose Composer XE 2013 SP1, assuming that that is the compiler version that you have and use). Once you have the MKL redistributables installed, you need to add the directory to PATH, or specify these additional directories in Visual Studio. Instructions for doing this are given in the PDF document https://software.intel.com/sites/default/files/article/184496/intel-mkl-configuring-in-microsoft-visual-studio.pdf ; see the section numbered 5 on the page numbered 14, called Configuring Intel Visual Fortran project to link with Intel MKL 10.2 or later version in
   Microsoft Visual Studio. Your MKL version will probably be 11.1.x, according to https://software.intel.com/en-us/articles/which-version-of-the-intel-ipp-intel-mkl-and-intel-tbb-libraries-are-included-in-the-intel .

There is nothing strange about being able to build and run a program that contains no calls to MKL routines (such as DGESV). The linker usually removes references to unused entry points. You are able to build and run such programs, and have been doing so for years.

[gib]

mecej4 wrote:

Quote:

gib wrote:

Bill, PathEditor is a very useful tool for editting the PATH:

https://www.softpedia.com/get/System/System-Miscellaneous/Path-Editor.shtml

I have not tried this specific software, but many such utilities edit the Windows-wide user and system paths. What we wish to probe, however, is the effective path that pertains to a specific Fortran program that Bill is running inside Visual Studio. That path is usually an augmentation/adaptation of the system-wide path, and those adaptations, made in configuration and batch files, is wherein the problem is probably situated.

Although there does not appear to be any change to PATH in this case.

[mecej4]

gib wrote:
... Although there does not appear to be any change to PATH in this case.

That's to be expected, since the two cases that he got the screenshots from are identical as far as configuration is concerned. In one of the cases, he commented out the only call that he had to an MKL routine.

[WSinc]

I would use the most current version of Visual Studio, except (as we already know) it has a

broken interface to the Fortran source code. There are a LOT of Fortran users out there.

So suggestions that involve C++ code don't do us much good..

anyway, where would I put the PATH command, if it has to be active at execution time ?

That is where the dynamic link is going wrong.

Is it under "Fortran libraries" or would it in the LINKER setup ?

Putting it BEFORE I invoke the Visual studio or Parallel studio would NOT have any effect, right ?

What would be the proper syntax ?

I still dont understand why the dynamic linker cant find the CORRECT library.

[WSinc]

I just want to reiterate - this problem is triggered ENTIRELY by ANY calls to an MKL BLAS routine.

Even when the call has wrong arguments.

Example: this two line program fails:

call DGESV()

end

Since it never starts execution, the call to DGESV does not have to be correct.

Of course it would crash as soon as it got there - -  BUT IT NEVER DOES.

[gib]

PATH is not a command, it is an environmental variable.  I think you need to learn to learn a bit more about the Windows operating system to be able to do program development in this system.

PATH is a list of directories that are searched when a program that needs to link DLLs (dynamic link libraries) is invoked.  These are not the first places searched, but typically these are where DLLs are found.  The PATH list is searched sequentially, therefore the first DLL file with the required name is the one linked.  If you have a DLL with the right name but from the wrong version that occurs earlier in the list than the file with the right version, it's possible that it will not be consistent with the .lib file that the compiler used.  This could lead to the entry point problem that you've encountered.

You need to explore Environmental variables, and how they are set.  For a start, at the command line, type:

set

If you type

set > set.out

the file set.out will show you the values of all your environment variables.

[WSinc]

OK, here is the output of the SET command, also the build log.

[WSinc]

So, why does this have to be so ****ing complicated ?

This used to be really easy to use - - 

I thought USE MKL library would have to point to the correct one  ?

ANYWAY, it seems to be pointing to the most recent version of compilers and libraries, 

thats probably the wrong one. But so far, no one seems to have any idea what the CORRECT one is.

I never did have parallel studio 2016 installed.

I have been using WINDOWS for my operating system for over 10 years,

and this is the only time I have encountered a problem like this.

What is the purpose of that missing entry point ?

[gib]

The missing entry point is just a result of the the fact that the .lib file that the compiler linked belongs to a different MKL version from that of the DLL that was found when the program was executed.  It is pointless to wonder about what that entry point was.  You need to study mecej4's posts carefully until you understand them, then follow his instructions.  If you don't want to follow the provided instructions you are wasting your time seeking help here.

[mecej4]

The attachment named "buildlog.txt" of #33 is actually a zip archive containing a number of files. It contains a number of uninteresting XML files, and a screenshot of the build log, which is what we want to examine, but that screenshot is presented as a 198 X 256 bit thumbnail image, which (to me, at least) is unreadable. Please send the actual HTML file, zipped up, or post a better screenshot.

The file "set.log" of #33 contains useful information. It shows signs of Bill's having installed the following versions of Intel Compilers: 2018U3, 2017U1, 2016U4, 2013SP1; if these were subsequently uninstalled, the PATH was not cleaned up. There is no occurrence of MKL in the environment recorded in "set.log".

Bill, if you have installed the MKL 2013 SP1 redistributable package as recommended in #27, there is one more task to do: configure Visual Studio to use MKL, as described in the link that I gave in #27. Did you do that yet?

[WSinc]

unfortunately, HTM files cannot be uploaded. That is a restriction that somehow got imposed by your software people.

anyway, I was told that the MKL components were supposed to be attached at LINKER time.

The only MKL link is when you say "use MKL" in the Fortran libraries menu.

There are entry points for the MKL routines in the BUILD LOG.

Its that MISSING entry point that is the problem.

are you telling me otherwise ? That is not the behavior I have always seen.

Why is it only looking for that entry point at execution time ?

[WSinc]

BTW, I ran that 2 line program on another machine - it runs fine, no mention of that

missing entry point.

The ONLY thing I need to reference the MKL libraries, is that choice under FORTRAN>LIBRARIES>USE MKL

That stuff  you were telling me might apply to C++ users, but I am not one of those.

Please dont confuse matters by giving C++ advice in a Fortran forum.