Difference between revisions of "Installing software on marvin"

From wiki
Jump to: navigation, search
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
 +
=Installing=
 
Software needs to be installed in:
 
Software needs to be installed in:
 
  /usr/local/Modules/modulefiles/tools/<software name>/<version number>/
 
  /usr/local/Modules/modulefiles/tools/<software name>/<version number>/
Line 39: Line 40:
 
  setenv STACKSROOTDIR ${prefix}
 
  setenv STACKSROOTDIR ${prefix}
 
  prepend-path    PATH  ${prefix}/bin
 
  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

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