Difference between revisions of "Installing software on marvin"
(One intermediate revision by the same user not shown) | |||
Line 43: | Line 43: | ||
=Removing= | =Removing= | ||
Move the folder and it's associated module file into /shelf/scratch/root/dustbin_for_modules means we have it ready if we need to restore it. | Move the folder and it's associated module file into /shelf/scratch/root/dustbin_for_modules means we have it ready if we need to restore it. | ||
+ | |||
+ | =Compiling= | ||
+ | The non-standard location of the gcc binaries can cause problems. For configuring, use the line below to help: | ||
+ | |||
+ | |||
+ | ./configure CXX=/usr/local/Modules/modulefiles/tools/gcc/4.9.3/bin/g++ CPP='/usr/local/Modules/modulefiles/tools/gcc/4.9.3/bin/g++ -E' --prefix=whatever | ||
+ | |||
+ | If that doesn't work, use the redhat developer toolset | ||
+ | |||
+ | == Red Hat Developer Toolset == | ||
+ | |||
+ | Seeing as the cluster runs with RHEL 6 which, though updated continuously, was released in 2011, there are various things it's incapable of. Primary among these is a gcc compiler with the C++ standard C++11, which alot of software is now using. THis requires gcc version 4.8 instead of the 4.4 RHEL6 uses. The solution is the poorly named developer toolset, which Red Hat makes available. To invoke it: | ||
+ | |||
+ | scl enable devtoolset-2 "bash" | ||
+ | |||
+ | This will open a new bash subprocess where the gcc will be version 4.8 |
Latest revision as of 13:33, 17 September 2018
Installing
Software needs to be installed in:
/usr/local/Modules/modulefiles/tools/<software name>/<version number>/
or
/shelf/modulefiles/
to make use of the modules feature. Beware using /usr/local/Modules/ as there's only 50Gb of space on /. Use /shelf/modulefiles/ for anything big (I'm looking at you interproscan).
The text files that tells modules that the software is there are located in:
/usr/local/Modules/3.2.10/modulefiles/<software>/<version number>
An example of which is below:
#%Module1.0##################################################################### ## ## proc ModulesHelp { } { puts stderr "\tStacks - loads Stacks 2.0Beta7c software \tSoftware available: \tcstacks \testacks \thstacks \tpstacks \trxstacks \tsstacks \tustacks " } module-whatis "loads Stacks version 1.41 software" module load perl samtools/0.1.19b sparsehash # for Tcl script use only set version 2.0Beta7c set prefix /usr/local/Modules/modulefiles/tools/stacks/${version} set sys linux64 setenv STACKSROOTDIR ${prefix} prepend-path PATH ${prefix}/bin
Removing
Move the folder and it's associated module file into /shelf/scratch/root/dustbin_for_modules means we have it ready if we need to restore it.
Compiling
The non-standard location of the gcc binaries can cause problems. For configuring, use the line below to help:
./configure CXX=/usr/local/Modules/modulefiles/tools/gcc/4.9.3/bin/g++ CPP='/usr/local/Modules/modulefiles/tools/gcc/4.9.3/bin/g++ -E' --prefix=whatever
If that doesn't work, use the redhat developer toolset
Red Hat Developer Toolset
Seeing as the cluster runs with RHEL 6 which, though updated continuously, was released in 2011, there are various things it's incapable of. Primary among these is a gcc compiler with the C++ standard C++11, which alot of software is now using. THis requires gcc version 4.8 instead of the 4.4 RHEL6 uses. The solution is the poorly named developer toolset, which Red Hat makes available. To invoke it:
scl enable devtoolset-2 "bash"
This will open a new bash subprocess where the gcc will be version 4.8