Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an issue which bugs me for a long time. I'm using the Intel C++ compiler which includes shell scripts to set up environment variables for library paths, include paths and more. Sourcing these scripts in .bashrc works like a charm for the terminal. Unfortunately, I need the environment variables in Mathematica and NetBeans C++ too, which brings me to the question, how to source the Intel scripts so that they are known by the GUI programs I start.

I searched the net carefully and I think I have tracked the issue down, although I don't have an explanation. One way of setting environment variables for Gnome seems to be to be to create an *.sh script in /etc/profile.d/ which is then executed by /etc/profile.

Although, regarding to this information the /etc/profile is not recommended, please note that I have a shell script which needs to be sourced and not only some export VAR=blub settings.

If I do this with the e.g. mklvars.sh script, it seems that not the complete file is sourced. Let me give a snip from the file to show what I mean

#! /bin/sh
#
# Copyright (C) 
# ...lot of boring stuff

CPRO_PATH=/opt/intel/composer_xe_2013_sp1.0.080
export MKLROOT=${CPRO_PATH}/mkl

SCRIPT_NAME=$0
MOD_NAME=mod

# .... some more code here ...

if [ -z "${MKL_TARGET_ARCH}" ] ; then

    echo
    echo "ERROR: architecture is not defined. Accepted values: ia32, intel64, mic"
    mkl_help

    else

    if [ -n "${LD_LIBRARY_PATH}" ] ; then OLD_LD_LIBRARY_PATH=":${LD_LIBRARY_PATH}"; fi
    export LD_LIBRARY_PATH="${CPRO_PATH}/compiler/lib/${MKL_TARGET_ARCH}: #.....

When I now logout/login again, the MKLROOT variable is defined but LD_LIBRARY_PATH was not adjusted. It seems anything which is a bit more complex than a simple export VAR is skipped when sourcing the .profile.


Question: Is there a convenient way of sourcing the compiler-variable scripts for an X-Session (in my case Gnome)? Does someone know what goes wrong here?


The obvious hack around this issue is to use the final variable definitions after sourcing the scripts manually and put them in the global profile. This has the disadvantage that I do this over and over again with every new update of the compiler.

Step-by-Step

Let me give a step-by-step showcase so that you see that I'm not completely nuts. For this I put the Math Kernel Library Script on pastebin and I start with the following situation:

  • I have not sourced the script in any bashrc, profile or other file.
  • I have logged out and logged in again

For the test we look at the $MKLROOT and $LD_LIBRARY_PATH which both should be changed by the script. Currently, they are not set when I check their values by

echo $LD_LIBRARY_PATH
echo $MKLROOT

When I source the file manually, I get:

source /opt/intel/composer_xe_2013_sp1.0.080/mkl/bin/mklvars.sh intel64
echo $MKLROOT
echo $LD_LIBRARY_PATH

# Output:
# /opt/intel/composer_xe_2013_sp1.0.080/mkl
# opt/intel/composer_xe_2013_sp1.0.080/compiler/lib/intel64:/opt/intel/composer_xe_2013_sp1.0.080/mkl/lib/intel64

When I put the source line into my ~/.bashrc and open a new terminal, both variables are set correctly as shown above. Now, I remove the source line from ~/.bashrc and put it into /etc/profile.d/intelCC.sh, save it and log off/on.

After the login, none of the variables are set, but I have an error message in my ~/.xsession-errors saying:

/usr/sbin/lightdm-session: 1: /etc/profile.d/intelCC.sh: source: not found

Now I replace source by a simple . so that /etc/profile.d/intelCC.sh contains now

. /opt/intel/composer_xe_2013_sp1.0.080/mkl/bin/mklvars.sh intel64

Same again: Save, log off and log on. Now there seem to be no errors in .xsession-errors related to this and finally:

echo $MKLROOT
# /opt/intel/composer_xe_2013_sp1.0.080/mkl

echo $LD_LIBRARY_PATH
# empty
share|improve this question
    
Are you sure your script enters the loop? –  terdon Oct 29 '13 at 14:48
2  
Could you show us the end of the if/else block? It looks like the export LD_LIBRARY_PATH is not run but since you have not included the rest of the script, I can't tell if it is within an if/else block. For example, in the script as shown, if MKL_TARGET_ARCH is defined, the export will not be run. –  terdon Oct 29 '13 at 14:57
    
I could post the code, but the mkl script is only one example. The Intel compiler comes with many variable scripts and the important thing is: they do work when I put source /path/compilervars.sh intel64 into my bashrc or when I source them manually. Is there an easy way to write some kind of debug message so that I can test which parts of the file are evaluated? –  halirutan Oct 29 '13 at 15:08
    
Not the whole code, just enough to make sure that the loop is being entered. As for debugging, either add an echo YES > /tmp/foo or something within the loop so you can be sure it is being run, or add the export line outside the loop to be sure that the loop is not the problem. –  terdon Oct 29 '13 at 15:13
    
@halirutan - your issue is sounding more and more as if there is a environment setup script that needs to be sourced prior to running the Intel compiler that you're missing in your setup. I would double check with whomever installed this for you (perhaps you) and see if there isn't a file provided by Intel that set's up the path etc. for these scripts so that they can just run. –  slm Oct 29 '13 at 15:35
show 3 more comments

1 Answer

up vote 1 down vote accepted

Confirm MKL_TARGET_ARCH is set

When you add this to the /etc/profile.d directory odds are the variable $MKL_TARGET_ARCH isn't set or hasn't been set yet, so the entire if/else block is essentially skipped.

You can test this theory by temporarily setting the $MKL_TARGET_ARCH just above the if/else statement and try logging in again to see if it worked.

MKL_TARGET_ARCH="..something.."
if [ -z "${MKL_TARGET_ARCH}" ] ; then

Installing Intel Compilers

I do not possess this compiler so I can't give you exact details but I've dealt with installing engineering applications for the better part of 15 years so I'm somewhat uniquely familiar with the domain.

In any case, when you install these types of tools you typically either have to create your own environment file or one is provided. I found this post regarding Intel's Fortran compiler but I'd be surprised if the products are that dissimilar.

If you look through this post you'll notice a step after installing (install.sh), where a file is copied to /etc/profile.d. This file contains the environment setup that needs to occur.

cp /opt/intel/Compiler/11.1/056/bin/ia32/iccvars_ia32.sh /etc/profile.d/

It would be my suspicion that a step similar to this needs to occur for this product as well. Double check your installation was done using distribution specific steps from this page:

Eventual Solution

if . works but source doesn't then you might be dealing with Bourne shell and not Bash. Bash supports both whereas Bourne shell (/bin/sh) does not.

If you have a look at this document then you see that this seems to be exactly where you problem lies.

Ubuntu 12.0x changed the link for /bin/sh from /bin/bash to /bin/dash. Intel installation scripts for 13.0.0.079 reference /bin/sh BUT assume/require this is bourne or bash (sh or bash) but are NOT compatible with dash.

share|improve this answer
    
For the C++ compiler it is a bit different. You don't have architecture specific scripts anymore, you specify the architecture as argument to one overall compilervars.sh which does the job. Furthermore, I don't want to copy it because if I just call it, I always get the most current version even after an update. Finally, no file is copied during the install to /etc/profile.d but you get a message that you have to source the variable scripts appropriately. Thanks for your answer. –  halirutan Oct 29 '13 at 16:41
    
@halirutan - you could write a script that does the sourcing of the latest compilervars.sh script, and put this script in /etc/profile.d, would be another example. –  slm Oct 29 '13 at 16:49
    
This is exactly how I do it and it works now like a charm except for one thing: Somewhere after the processing of the profile my LD_LIBRARY_PATH gets unset. If you can spare a minute and have an idea how to debug this, I'm in the chat. –  halirutan Oct 29 '13 at 16:51
    
@halirutan - I can't chat now, but another suggestion would be to add a set -x before commands in these files to enable a more verbose debug message as they're sourced. You typically enable it with set -x and disable it with set +x. –  slm Oct 29 '13 at 16:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.