I’ve been compiling things from source for years, but never really understood how to make something a “system default.” I need to compile OpenMPI and did so, but now I’m not sure how to make it the system default. I tried mpi-switcher-menu but the version I compiled (in /usr/local/Ompi) doesn’t even show up in the menu. I’ve heard of various “tricks,” like prepending the particular MPI’s directory you want to use, but which seems to find only the system default. (You can see below that the system default OpenMPI is still being found - and I’m not sure if I change the system default that I won’t break something else…)
Setting up Intel Compilers...
Intel Compilers Ready!
patti@OS-Linux:~> which mpicc
/usr/lib64/mpi/gcc/openmpi/bin/mpicc
patti@OS-Linux:~> which mpich
which: no mpich in (/opt/intel/composer_xe_2011_sp1.10.319/bin/intel64:/opt/intel/composer_xe_2011_sp1.10.319/bin/intel64:/opt/intel/composer_xe_2011_sp1.10.319/bin/intel64:/usr/lib64/mpi/gcc/openmpi/bin:/home/patti/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/intel/composer_xe_2011_sp1.10.319/mpirt/bin/intel64:/opt/intel/composer_xe_2011_sp1.10.319/mpirt/bin/intel64:/opt/intel/composer_xe_2011_sp1.10.319/mpirt/bin/intel64)
patti@OS-Linux:~> which mpif90
**/usr/lib64/mpi/gcc/openmpi/bin/mpif90**
patti@OS-Linux:~> mpi-selector-menu
Current system default: openmpi-1.4.3
Current user default: <none>
"u" and "s" modifiers can be added to numeric and "U"
commands to specify "user" or "system-wide".
1. openmpi-1.4.3
U. Unset default
Q. Quit
Selection (1-1[us], U[us], Q):
(CODE wrapped - please move to compilers/scripting forum - thanks!!)
Hi
Its all the order of your PATH and env user settings, you need to tweak your ~/.profile and adjust as required.
Check the output from the following commands;
env
echo $PATH
The library path can also be tweaked on the fly with LD_LIBRARY env
setting. You can also script it into you ~/bin directory so it just
sets up for that shell session.
–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default
up 23:17, 3 users, load average: 0.43, 0.25, 0.23
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU
Thanks for the reply, Malcom! I knew a little about the PATH and LD_LIBRARY_PATH statements, but not env. I know how to
export PATH=/somepath:$PATH
(although I don't know how/why this is different: export PATH=/somepath:{$PATH} )
I guess I’ll check to see if there’s a man page on ‘env’
I’ve never used .profile, only .bashrc. I’m not exactly what sticks where and when. I think if I .bashrc something like:
PATH=/somepath:$PATH
then it will prepend /somepath and leave $PATH alone between launches of the bash shell. But if I put that in .profile, it will keep prepending a new instance of /somepath to $PATH so that it gets bigger with each boot.
I found a man page for env - it’s unclear - hmmmm… I wonder if there’s a single text file somewhere that has all the information in it and is editable?
I just now ran across something that I never noticed before and am now confused about - when I set up the intel compilers, I do it with a source command in .bashrc:
source /opt/intel/bin/ifortvars.sh intel64
Now that I actually think about it - that is a shell file - and I presume executable! So why am ‘sourcing’ it rather than running it?
Sourcing is as if the lines were in the place where the source statement is. That means the lines are executed in the same process that runs where the source statement is. Caling a scritp makes this a seperate process. That looks unimportant until you realise that when the called/sourced script contains:
MONKEY="Langur"
when sourced, it is as if this statement was in place of the source statement, which means that that value is available for the rest of the calling script/process.
While, when it is done in a seperate process, it is only available in the seperate process and thus unknown (or unaltered if MONKEY was allready defined) in the calling process.
Thus when you need the statements to influence the currecnt script/process (mostly that will be setting variables like MONKEY here), you should source, else you will have nothing. The obvious example being .profile., which is sourced to make all the settings there available to the calling process (the login shell) and thus most of them (being exported to the environment) to all the offspring processes during your session.
Such a bunch of statements to be sourced is normaly not made executable (why should it, it is not executed as a pocess), and it does not need a “shebang” (the #!/bin/bash) as the first line (the statements are executed by the shell that executes the main script, that is the process). Thus imho because these two things are not needed, they should not be there, only creating confusion when they are.
I do not know where you found this, but it will result in a weird PATH value where the first and last variable of the original PATH will be destroyed because they are no longer directory pathes. See here:
henk@boven:~> echo $PATH
/home/henk/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/home/henk/.local/bin
henk@boven:~> which vi mmcheck
/usr/bin/vi
/home/henk/bin/mmcheck
henk@boven:~> PATH=/lala/lolo:{$PATH}
henk@boven:~> echo $PATH
/lala/lolo:{/home/henk/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/home/henk/.local/bin}
henk@boven:~> which vi mmcheck
/usr/bin/vi
which: no mmcheck in (/lala/lolo:{/home/henk/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/home/henk/.local/bin})
henk@boven:~>
Because the second item in the PATH variable is now {/home/henk/bin, which does not exist of course, executables in /home/henk/bin can not be found anymore.
OK, I found that syntax (with the “{}”) somewhere online but couldn’t find what it actually meant. Thanks for telling me it must have been an error on that web page.
If I understand the responses to my question, priority of use is set by first encounter along the path - hence always prepend the directory containing the libs/exes you want used. The trouble I have is that some software spawns shells of various types and so the PATH variable may change within scripts. So I was sort of looking for an system-wide analog to Windows’ PATH variable - something all shells would inherit.
I am not quite sure I understand what you mean, but instead I will simply try to explain how it works with environment variables.
A process inherits all the variables from it’s parent. It may change them, but that will only influence child processes, never parents.
This is all true for all processes, does not matter if the process runs a shell. But when it is a shell, it is of course easy to change things in the program (the shell script), it is less easier in a binary executable, because that involved compiling. But a binary executable can of course also change environment variables and spawn off new processes that will then have the changed variables.
What Windows does or does not I have almost no knowledge about, thus I can not help you here because I can not follow you in your comparisson.
And about silly things in web-sites. I would allways prefer the man pages. And* man bash t*ells:
PATH
The search path for commands. It is a colon-separated list of directories in which the shell looks for commands (see COMMAND EXECUTION below). A zero-length (null) directory name in the value of PATH indicates the current directory. A null directory name may appear as two adjacent colons, or as an initial or trailing colon. The default path is system-dependent, and is set by the administrator who installs bash. A common value is ``/usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin’'.
Thus the : seperated items should contain directories. And as most directories have no { or } in their names, adding these characters to the string that is the value of PATH is most often not a good idea IMHO.