Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646

Not able to "compilervars"

Vishnu
Novice
1,505 Views

Hi!

I just installed the 'Intel Parallel Studio XE (Cluster edition)' on my Ubuntu machine. Because I want to use the fortran compiler, I looked up its documetation and followed the instructions. One of the first is to set environment variables.I get the output that follows, when I run the following command:

$ ./compilervars.sh intel64
bash: ./compilervars.sh: 36: /opt/intel/compilers_and_libraries_2016.1.150/linux/daal/bin/daalvars.sh: Bad substitution
bash: ./compilervars.sh: 37: /opt/intel/compilers_and_libraries_2016.1.150/linux/daal/bin/daalvars.sh: Bad substitution

I don't quite understand what is wrong.

If I start a new terminal and type 'ifort', it does not recognize it. So the linking has not happened. I don't know what else is wrong.

Can someone help me out?

Thanks

Vishnu

0 Kudos
1 Solution
Kevin_D_Intel
Employee
1,505 Views

There's nothing wrong with it. It appears you have misunderstanding of what this script is designed to do. After you 'source' it, you should enter the 'ifort -V' command in the *same* terminal window in which you 'source' it. The reason is, the script sets up the necessary environment settings to enable the use of the compiler. So when you open a new terminal and type 'ifort -V' before you 'source' the compilervars initialization script then you can expect the 'ifort' command to return an error of not found just as you showed.

The third form of command-line above that you use that produces the error, (i.e. ./compilervars.sh intel64 ), has a typo in it that I mentioned before needs to also be corrected in our documentation. It is missing a leading "." (dot). The correct form is: . ./compilervars.sh intel64 (Notice the extra "." that appears before the path-component "./")

In this "dot" form of command-line, when you leave off the extra leading "." (dot), the compilervars script essentially executes in the current shell instead of running it in the manner that is equivalent to the 'source' command where it initializes the underlying shell. Running the script in this way is incorrect (hence the errors you note). My advice is to simply do not use the third form of the command that you showed above, and that includes even if you use it correctly with the leading "." (dot). Just use the 'source' form which you have shown above does run correctly.

When you use 'source' or the proper "." (dot) form of the command, the initialization script does not print any output. After you run it, then type 'ifort -V' to see that the compiler is accessible within that terminal session.

Hopefully this helps.

View solution in original post

10 Replies
Kevin_D_Intel
Employee
1,505 Views

You just have a malformed command and that leads to the error. After cd-ing into the /opt/intel/bin, you can use this form of the command: source ./compilervars.sh intel64

Or, when you do cd into the directory, you can use the complete path with the command: source /opt/intel/compilervars.sh intel64

The documentation here appears to correctly include source command.

Vishnu
Novice
1,505 Views

Kevin Davis (Intel) wrote:

You just have a malformed command and that leads to the error.

I think it is ok; I did what was in that page you referenced. The part before the $ just is the directory i'm in.

Kevin Davis (Intel) wrote:

After cd-ing into the /opt/intel/bin, you can use this form of the command: source ./compilervars.sh intel64

How do I know if the command carries through successfully ? I don't think it worked, because 'ifort' is still not a recognized command in the terminal.

It tried again with 'sudo su' access, and with the .csh file, instead of the .sh file. Then, this is what I end up with:

# source compilervars.csh intel64
bash: compilervars.csh: line 32: syntax error near unexpected token `$argv[1]'
bash: compilervars.csh: line 32: `switch ( $argv[1] )'

Still stuck.

Kevin_D_Intel
Employee
1,505 Views

Well you are now source-ing the "csh" version under a bash shell which will not work. You need to source the ".sh" version under the bash shell. Please use the command-line I provided in my earlier reply.

After you run the source command, to display the compiler's version details you can just enter the command: ifort -V

I see the missing extra "." in the documentation for the non-source form of this command. I'll notify the Documentation team.

Vishnu
Novice
1,505 Views

Kevin Davis (Intel) wrote:

You need to source the ".sh" version under the bash shell. Please use the command-line I provided in my earlier reply.

I ran it again in three different ways, from the directory: /opt/intel/bin :

# source ./compilervars.sh intel64

# source compilervars.sh intel64

# ./compilervars.sh intel64
./compilervars.sh: 36: /opt/intel/compilers_and_libraries_2016.1.150/linux/daal/bin/daalvars.sh: Bad substitution
./compilervars.sh: 37: /opt/intel/compilers_and_libraries_2016.1.150/linux/daal/bin/daalvars.sh: Bad substitution

The first is as you suggested. It gives no output. The same with the second. The third is as is given in the documentation. It gives the error above.

Kevin Davis (Intel) wrote:

After you run the source command, to display the compiler's version details you can just enter the command: ifort -V

Running this command in a separate terminal gives the following after each of the above three ways of doing it.

~$ ifort -V
ifort: command not found

I am attaching the compilervars.sh file here. Could it be that there is something wrong with it?

Thanks!

Kevin_D_Intel
Employee
1,506 Views

There's nothing wrong with it. It appears you have misunderstanding of what this script is designed to do. After you 'source' it, you should enter the 'ifort -V' command in the *same* terminal window in which you 'source' it. The reason is, the script sets up the necessary environment settings to enable the use of the compiler. So when you open a new terminal and type 'ifort -V' before you 'source' the compilervars initialization script then you can expect the 'ifort' command to return an error of not found just as you showed.

The third form of command-line above that you use that produces the error, (i.e. ./compilervars.sh intel64 ), has a typo in it that I mentioned before needs to also be corrected in our documentation. It is missing a leading "." (dot). The correct form is: . ./compilervars.sh intel64 (Notice the extra "." that appears before the path-component "./")

In this "dot" form of command-line, when you leave off the extra leading "." (dot), the compilervars script essentially executes in the current shell instead of running it in the manner that is equivalent to the 'source' command where it initializes the underlying shell. Running the script in this way is incorrect (hence the errors you note). My advice is to simply do not use the third form of the command that you showed above, and that includes even if you use it correctly with the leading "." (dot). Just use the 'source' form which you have shown above does run correctly.

When you use 'source' or the proper "." (dot) form of the command, the initialization script does not print any output. After you run it, then type 'ifort -V' to see that the compiler is accessible within that terminal session.

Hopefully this helps.

View solution in original post

Vishnu
Novice
1,505 Views

Kevin Davis (Intel) wrote:

There's nothing wrong with. It appears you have misunderstanding of what this script is designed to do. After you 'source' it, you should enter the 'ifort -V' command in the *same* terminal window in which you 'source' it. The reason is, the script sets up the necessary environment settings to enable the use of the compiler. So when you open a new terminal and type 'ifort -V' before you 'source' the compilervars initialization script then you can expect the 'ifort' command to return an error of not found just as you showed.

 [ ... ]

When you use 'source' or the proper "." (dot) form of the command, the initialization script does not print any output. After you run it, then type 'ifort -V' to see that the compiler is accessible within that terminal session.

Within that terminal, 'ifort -V' does work, but then if 'ifort' does not work outside, then do I have to 'source compilervars.sh' every time I need to compile something?

Thanks

mecej4
Black Belt
1,505 Views

As long as you stay in the console window in which you sourced the script, the compiler will be available. Within that window, you should source the script only once.

Perhaps an analogy will help. Sourcing the shell script sets up an environment that builds on the default environment. Compare this to entering a room in a house. Some rooms have tables, others have beds, and the kitchen has appliances not found in any other room. As long as you stay in the kitchen, you can use the stove, etc. If you step out from the kitchen and into a bedroom, the kitchen appliances are not available. To reuse the stove, you have to reenter the kitchen, and turn on the light first there -- source the script for that environment.

Now and then, I find myself needing two or more kitchens -- for example, an ifort-16 kitchen and an ifort-15 kitchen. That is when I appreciate the power that the creators of the OS have given us -- I can snap my fingers and have a new kitchen with its own unique environment.

Kevin_D_Intel
Employee
1,505 Views

You must source the script *once* after each time you log into the system under a new terminal window and this enables you to use the compiler in that window until you log out of it. So, yes, each time you start a new terminal window you need to source the script once.

You can enable the automatic 'source' of the script for each new terminal window by adding the 'source' command in your default environment setup scripts (i.e. .bashrc). I sense you might be new to Linux so perhaps it is best to source the script manually for now and consider customizing your setup scripts in the future.

Vishnu
Novice
1,505 Views

Okay, I finally understand. I think I will use the bashrc route, because I use a separate editor to program, and it executes on a new terminal every time. I hadn't quite understood that this needed to be done because when I use gfortran, I didn't need to do anything like this.

Shouldn't the procedure to add this to bashrc, maybe be in the documentation?

Thanks a lot!

Kevin_D_Intel
Employee
1,505 Views

Glad you are over this hurdle. The documentation topic I cited in my reply #2 does mention making the setup automatic by changing one's startup file. The example provided uses .bash_profile, which is another alternative. gfortran installs into various paths automatically added to your various environment variables (like PATH) by default so users don't have to enhance their environment settings to use it.

Good luck going forward.

Reply