Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Steven_G_
Beginner
1,138 Views

problems setting MKL environment variables

Hello,

I have searched the forums for a solution to my problem but haven't seen a similar topic.

I have been unable to get the scripts that set the mkl environment varaibles (described here: https://software.intel.com/en-us/node/528500 ) to work.  I am working on 64-bit ubuntu 14.04.  Correspondingly I am running the script "./opt/intel/mkl/bin/intel64/mklvars_intel64.sh"  but when I check the values of the environment variables "echo $MKLROOT" they are not being set.  Any suggestions would be appreciated.  Thank you.

 

0 Kudos
8 Replies
mecej4
Black Belt
1,138 Views

You need a space between the '.' and "/opt...". The latter is the path to the script, and the '.' tells the shell to "source" the script.

Unless your current working directory is the root of the filesystem, without that space the path is incorrect and you would probably see a message about the directory not being found.

If you are in the root directory when you execute the script, the correct file is found, but the commands in the script are executed without affecting the parent environment.

Steven_G_
Beginner
1,138 Views

Thank you for your response.  I apologize, I didn't copy and paste the command and ommited the space when I typed it.  I am executing the following commands:

s*****@cs-cg-dev:~/research/FEM/CMSv2/build$ . /opt/intel/mkl/bin/intel64/mklvars_intel64.sh
s*****@cs-cg-dev:~/research/FEM/CMSv2/build$ echo $MKLROOT

s*****@cs-cg-dev:~/research/FEM/CMSv2/build$ 

 

Gennady_F_Intel
Moderator
1,138 Views

 
  source /opt/intel/mkl/bin/intel64/mklvars.sh intel64  
Steven_G_
Beginner
1,138 Views

Thank you both very much for your assistance.  

DarioMangoni
Beginner
1,138 Views

Hi,
I'm having a similar, although slightly different, problem with mklvars. I'm running WIN8.1.
I run "mklvars.bat intel64" that sets all the env vars that I need but unfortunately they are set with the SET command in the batch file. That means that those variable are not permanently stored as env vars but they exist only up until the command prompt is closed, i.e. if I echo %MKLROOT% I'll get the path to MKL library, but I can't see them in Computer>Advanced properties>Env variables... and they aren't there when I close and re-open the cmd window.

So: how can I use those env vars if they disappear? I thought I need to pre-run mklvars at every build but I don't think that's the cleverest idea... Should I change SET with SETX?

Thanks in advance

TimP
Black Belt
1,138 Views

Better than putting mkl environment variables into the stored Windows environment would be to arrange to run mklvars whenever you start a session.  The compilervars .bat runs mklvars.bat automatically, so it's unusual to need mklvars by itself.

Intel compiler install used to have a screen option to set the stored environment variables, but it didn't clean up stuff from previous installations, and for other reasons proved undesirable (among them the obstacle to switching between 32- and 64-bit mode).

My own strong preference on win8.1 and win10 is to run startbutton and cygwin shell.  Opening up an Intel tools window from startbutton menu automatically sets the compiler and mkl environment variables.  It's a bit strange that Microsoft asked Intel (in effect) not to make it convenient without adding 3rd party tools. I haven't been able to see whether they are sorting this out for win10.

You may object (as Intel apparently does) to the need to edit the ifort.cfg and icl.cfg each time you upgrade a compiler in order to preserve the linker path settings when you start cygwin.

mecej4
Black Belt
1,138 Views

There are major deterrents to setting global environment variables, because there is no single "fits-all" environment. For instance, let us say that you have both 32-bit and 64-bit versions of IFort installed. Obviously, you would have 32-bit and 64 bit versions of libraries (such as MSVCRT.LIB and LIBIFCORE.LIB) in different directories. In order for the linker to do its job, it would need to choose the correct version, which it does by looking up the LIB environment variable. If you had LIB set in the global environment, it would be correct only for one of the these two situations: 32-bit and 64-bit builds. For similar reasons, you do not want wrong tools with the same names (such as LINK from MSVS and link from Cygwin) used. The batch file that is used after opening a configured command window serves to set up an environment that is suitable for the intended use. For working in command-line mode, things are designed to work correctly.

If you build inside an IDE, the situation is a bit different. That is where the project files come in, and provide information to the build system about whether to target 32-bit or 64-bit, where to find include files and libraries, etc.

DarioMangoni
Beginner
1,138 Views

Hi,
You're absolutely right, I see the point: actually I didn't explain my real problem that is in runtime.

Providing location of libraries and header files is by far the simplest thing (once you know the MKL root folder*).
The project I'm developing is making use of CMake and, once you asked the user where MKL is installed*, you can set include directories and libraries with a bunch of commands.
But this is compile time.

When the executable starts another problem arises. Without any "suggestion" (that is PATH envvar) of where the dlls are the executable won't start.
Ok. Problem 1: Where are the dlls stored? How can I provide this info, once I know MKL root folder*?

  1. I can copy dlls in Windows\System32 once ( joking :-) );
  2. I can copy them in the exe folder (less joking) --> this means copying tens (or tons?) of Mb
  3. I can modify PATH --> what about running x32 and x64? I have to change PATH everytime? :-(
  4. In Visual Studio there's a flag in Project Properties > Intel Performance Libraries > Use Intel MKL that does the job but I have to be multi-platform and multi-IDE!

I can't see any other way to do that, but I hope there are...

Problem (*): All the asterisks mean that someone needs to provide the information about where is MKL root folder. Do I have to manually provide MKLROOT? I'm pretty sure that the answer is YES.

Yours,
Dario

Reply