Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
7 Views

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

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

0 Kudos
37 Replies
Highlighted
New Contributor II
7 Views

You could make sure that in

You could make sure that in the PATH environment variable the path to the libraries you want to be used comes before any of the others.  I'm not an Intel Fortran guru, so I could well be wrong.

Edit:  I just remembered that this applies to the DLLs linked at runtime, not to the libraries linked at compile time.

0 Kudos
Highlighted
Black Belt
7 Views

https://software.intel.com/en

https://software.intel.com/en-us/articles/using-older-intel-visual-fortran-versions-in-different-mic... explains how to select among installed sets of compilers and libraries.  

compiler-select-vs10.png

Clicking on the ... next to Libraries opens up an editable list that may look like this:

Screenshot_10.jpg

Note the highlighted line - this is what identifies the MKL associated with the selected compiler version. If you want to use a different version, add the path to that above the highlighted line. You will also want to adjust the Includes list.

I will note, as several of us have said in one of your other threads, that if the MKL DLLs found on PATH are not compatible with the libraries you selected, you'll have the same problem.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Black Belt
7 Views

Quote:gib wrote: You could

gib wrote:
You could make sure that in the PATH environment variable the path to the libraries you want to be used comes before any of the others.  I'm not an Intel Fortran guru, so I could well be wrong.

Edit:  I just remembered that this applies to the DLLs linked at runtime, not to the libraries linked at compile time.

Indeed; just as the DLLs are searched for using %PATH%, the LIBs are searched for using the environment variable %LIB%, and include files (and Fortran MOD files) are searched for using %INCLUDE%.

0 Kudos
Highlighted
Black Belt
7 Views

Quote:mecej4 wrote:

mecej4 wrote:

Indeed; just as the DLLs are searched for using %PATH%, the LIBs are searched for using the environment variable %LIB%, and include files (and Fortran MOD files) are search for using %INCLUDE%.

Yes - in addition to the paths set in Tools > Options.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor I
7 Views

OK, I am quite happy to put

OK, I am quite happy to put that PATH command to my build setup. But does that govern the dynamic link library

at EXECUTION time ?

How do I find out which library set is needed to satisfy that missing entry point I keep seeing?

In other words, when it starts execution, it keeps looking for that MKL_BLAS_CGEM2VC entry point.

That probably is in ONE of the libraries, but apparently it does not need it until I am about to start execution.

since the VERBOSE linker steps say "no errors."

It might be a wrong version of the MKL library - I have 5-6 of those installed, but I would have to know

which library has that missing entry point.

apparently it must be associated with a BLAS routine, given the name you see.

Is there a way to get a list of entry points contained in a given library ?

We dont really know what libraries are in a compatible set, do we ?

That special command "USE MKL library" does not come anywhere near solving this issue.

 

I will upload the screen shot showing the problem (again) - - It keeps rearing its ugly head.

One thing that makes this more difficult is: the ones that DO find it do not tell me WHERE they found it.

Otherwise this problem would be resolved..

 

 

0 Kudos
Highlighted
Black Belt
7 Views

Here is a short diagnostic

Here is a short diagnostic program in C that you can run in Visual Studio and obtain the path in the run time environment. Create a new C console application, paste the source code into a new file with the .C suffix, build and run.

The program will output the path to a CMD window and pause. Copy the contents of the CMD window to a file, and press RETURN to terminate the program. Share that output file here. If we see paths that should not have been present in PATH, we can go about deciding how to fix that.

#include <stdio.h>
#include <stdlib.h>

int main(void){
char buf[4000],*env,*p;
env=getenv("PATH");
//replace ';' by newline in %PATH%
p=env;
while(*p){
   if(*p==';')*p='\n';
   p++;
   }
puts(env);
gets(buf); // pause before exiting, so user can view output
}

Your approach will not yield a solution. After a DLL has been loaded and found not to have a certain entry point, it is too late to fix things. All that we know at that point is that the wrong version of the DLL was loaded. My recommendation may help find where that wrong version is located, so we can fix PATH such that that wrong version is never seen.

0 Kudos
Highlighted
New Contributor II
7 Views

mecej4, the screenshot that

mecej4, the screenshot that Bill posted in the previous post shows the location of the detected DLL (mkl_sequential.dll) that lacks the entry point apparently needed by the mkl_sequential.lib that was linked at compile time.  Would it not be useful to discover the location of that .lib?  I don't know how to do this.

Edit: I guess an alternative would be to make the compiler find the .lib that lives in the same place as that DLL, using the approach Steve suggested in post #3.  This would entail inserting the path in the screenshot (everything before "\mkl_sequential.dll") ahead of the MKL path in the list.

 By the way I'm just guessing that the .lib files are in the same directory as the .dll files.  In my old installation (my MKL files are all dated 2009), I see ...mkl\ia32\lib with the .lib files and ...mkl\ia32\bin with the DLLs, but based on Bill's screenshot the DLL is not in a 'bin' directory.

0 Kudos
Highlighted
Black Belt
7 Views

Gib, it's a bit more

Gib, it's a bit more complicated. I believe that the problem lies with another MKL DLL that referenced mkl_sequential.dll. I believe that that DLL, whose name we do not find in the screenshot or the description, is from an older version of MKL. The older DLL probably contained references to the routines that were present in the older version of mkl_sequential.dll but are absent in the present version of the same DLL.

The fix would be quite easy if one knew what was installed on Bill Sinclair's machine and what the path was. He has installed several versions of Parallel Studio/Intel Fortran and probably has ended up with corrupted environmental variables. If he could find and report the DLL properties (file sizes, dates, version numbers), those could be used to track the problem. Likewise, a tool such as Dependency Walker could be used. One one could set breakpoints upon DLL loads in the debugger. However, these are lower level tools and many users are not comfortable using them.

We established in one of his threads on this topic (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/785552#comment-1926870) that he has had several versions of MKL installed on his PC. He may have uninstalled and reinstalled several versions of Visual Studio and Parallel Studio subsequently, so it is not clear what is on his PC at this point.

0 Kudos
Highlighted
New Contributor I
7 Views

What complicates the matter

What complicates the matter is that the missing entry point

only shows up right at execution time.

I dont know whether the PATH variables or adding other libraries to the build has any effect on that.

as I said before, it goes thru both passes of the linker without showing any errors.

 

I am currently using Intel parallel studio XE 2013 SP1 since it does the right things with my source code.

But I dont think I have any control over what DYNAMIC LINK library is used. Of course, that screen dump 

currently it is telling us what library it is trying to get  the missing entry point from. (2016.4.206)

 

It is trying to use the "fortran Module wizard" Is that any help ?

 

0 Kudos
Highlighted
Black Belt
7 Views

Bill, the screenshot of #6

Bill, the screenshot of #6 shows 2018, not 2016. If you really used XE 2013 SP1, the date/version of the DLLs should be 2014, not 2016 or 2018. No MKL DLLs more recent than 2013 SP1 should be on PATH.

Which DLLs are used partly depends on the PATH in effect when your program is run. Please build and run the C program of #7 and report the results. Having that information may help undo the logjam.

0 Kudos
Highlighted
New Contributor II
7 Views

mecej4, is it the case with

mecej4, is it the case with recent MKL versions that the .lib and .dll files are all installed in the same directory?  If so, and since it seems that we know where the DLLs are found (based on where mkl_sequential.dll is found), wouldn't it be sufficient to ensure that the .libs are linked from the same place?

Dependency Walker is easy to install and use, and that would tell conclusively which DLLs are being used.

 

0 Kudos
Highlighted
Black Belt
7 Views

Gib, Intel made major changes

Gib, Intel made major changes to the layout of the directories in which tools, include files, linker input files and runtime files are placed, around 2015-2016. Your version (Ifort-11 and MKL 10.x?) probably has the old layout. The current set of tools will not even run on a 32-bit Windows PC.

0 Kudos
Highlighted
New Contributor II
7 Views

No, as I pointed out, the MKL

No, as I pointed out, the MKL directory structure of my old installation is quite different from what Bill has.  My question to you is this: in your MKL installation (presumably recent), is mkl_sequential.dll, and the rest of the MKL DLLs, in the same directory as the .lib files?

0 Kudos
Highlighted
Black Belt
7 Views

No, but the relative

No, but the relative positions of the LIB and DLL directories of a given release are fixed. For example, the 32-bit MKL *.lib files are in 

     ...\compilers_and_libraries_2018.3.210\windows\mkl\lib\ia32

and the matching 32-bit MKL *.dll files are in

     ...\compilers_and_libraries_2018.3.210\windows\redist\ia32\mkl

For other libraries such as IPP, DAL, etc., simply replace "mkl" by the product name and you get one pair of directories for each product.

Similarly, replace "ia32" by "intel64" and you have the 64-bit libraries and DLLs.

You should be able to gather from this information that mixing the new and old versions of Parallel Studio can easily cause problems. To avoid such problems, if any product installer asks me if it should change the system environment variables, I refuse. I back-up the environment now and then so that I can revert to it if an installer changes the environment without seeking approval.

0 Kudos
Highlighted
New Contributor I
7 Views

OK, I got a screen shot (see

OK, I got a screen shot (see attached) showing where all the compilers and libraries are located.

The parent directory is: program files(X86)/intelSWtools

My machine is a 64-bit DELL CPU, so I think thsee compilers and libraries are supposed to accommodate both 32 and 64 bit CPUs.

If you need any more detail about the these library file locations, please let me know.

as I said before, I think the key to this whole issue is:

 

Where is that missing entry point supposed to be located ?

I wonder if there is a way to list the entry points of each of these libraries ?

apparently it has no trouble in locating DGESV.- otherwise the linker would fail

0 Kudos
Highlighted
New Contributor II
7 Views

Based on that info, mecej4,

Based on that info, mecej4, it seems that Bill's compiler needs to look for the MKL libraries in:

C:\Program Files(x86)\IntelSWTools\Compilers_and_libraries_2018\Windows\mkl\lib\ia32

and he should be able to ensure this by following Steve's suggestion in post #3.

0 Kudos
Highlighted
Black Belt
7 Views

Quote:gib wrote: Based on

gib wrote:
Based on that info, mecej4, it seems that Bill's compiler needs to look for the MKL libraries in:

C:\Program Files(x86)\IntelSWTools\Compilers_and_libraries_2018\Windows\mkl\lib\ia32

and he should be able to ensure this by following Steve's suggestion in post #3.

Sorry, no. See #5; Bill is using Parallel Studio XE 2013-SP1 (2014).

0 Kudos
Highlighted
New Contributor II
7 Views

I see.  So assuming that the

I see.  So assuming that the compiler really is using the .lib files appropriate for that compiler version, Bill needs to find out where the MKL DLLs for that version are located, then ensure that the directory appears in the PATH before any other version's MKL DLL directory.

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

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

0 Kudos
Highlighted
New Contributor I
7 Views

Well, I could not do anything

Well, I could not do anything with post #5, it only wants to ADD A FORTRAN FILE.

How do I add a C++ file ?

It appears that the ones that WORK are accessing the same libraries as the ones that CRASH.

I cant figure out why it needs that missing entry point.

I guess no one anywhere knows ?

 

BTW, I could not do anything with that PATH editor. It asks me "How do you want to open this ?"

I noticed there are some other posts about missing entry points.

 

0 Kudos