install fails looking for modulecmd
#2924
Comments
|
@tgamblin I'll try to have a look. If I am not wrong this code was part of the support for Cray, and is reached either if a compiler has a module specified or if an external has a module specified. |
|
Maybe I should be pinging @becker33 and @mamelara then. @mpbelhorn: I seem to recall you having issues where |
|
I think @alalazo is right about when We also have a non-Cray system that uses |
|
I am also affected by this bug (on a CentOS 7 system, module command = |
|
@mpbelhorn I thought that @Exteris Does your site's implementation of modules not call modulecmd as part of its execution? Or is the issue that @tgamblin @alalazo You are correct about the origin of this piece of code. It should only be called when we already know we need modules, but I may have to think more about how to find modulecmd when it's not in the user's path. |
|
@becker33 module() is set into the users path as a function:
when using external openmpi. |
|
I am currently trying to create a small wrapper for my module system. output like this is produced: and spack hangs on spack install. |
|
Hi @Exteris ... welcome on Marconi, think I had the same problem on another CINECA cluster |
|
Hi @luigi-calori Thanks :) |
|
likely is the which('modulecmd') thas can not work with this kind of pure tcl modules.... |
|
Ah, I have made a mistake here. The wrapper only needs to be: #!/bin/bash
$TCLSH /marconi/prod/opt/environment/module/3.2.10/none/modulecmd.tcl $*which outputs: modulecmd python show openmpi/1-10.3--gnu--6.1.0
-------------------------------------------------------------------
/cineca/prod/opt/modulefiles/base/compilers/openmpi/1-10.3--gnu--6.1.0:
prereq gnu/6.1.0
conflict openmpi
setenv OPENMPI_HOME /cineca/prod/opt/compilers/openmpi/1-10.3/gnu--6.1.0
setenv MPICC mpicc
setenv MPICXX mpicxx
setenv MPIF90 mpif90
setenv MPIF77 mpif77
setenv MPIFC mpifort
prepend-path PATH /cineca/prod/opt/compilers/openmpi/1-10.3/gnu--6.1.0/bin :
prepend-path LD_LIBRARY_PATH /cineca/prod/opt/compilers/openmpi/1-10.3/gnu--6.1.0/lib :
prepend-path MANPATH /cineca/prod/opt/compilers/openmpi/1-10.3/gnu--6.1.0/man :
module-whatis OpenMPI
-------------------------------------------------------------------and yields a |
|
@luigi-calori I have put Mostly it is just me trying to use spack with marconi provided modules. New script: #!/bin/bash
$TCLSH /marconi/prod/opt/environment/module/3.2.10/none/modulecmd.tcl $* 2>&1 | tail -n +2 1>&2 |
|
@Exteris : I saw same error on Marconi (just getting started on this system). Once you got all working, it will be very helpful if you summarise issues you encountered and workaround/fixes. |
|
MM... interesting, let me know how it proceeds as I' m as well interested l in building things with spack on Cineca clusters, specifically Marconi. For gcc6 I' ve tried to use that not using modules... the modulecmd wrapper is a smart idea... even if a hacky one |
|
I've been able to install scotch just now, with the script in the post above named packages:
openmpi:
modules:
openmpi@1.10.3%gcc@6.1.0: openmpi/1-10.3--gnu--6.1.0
buildable: False
intelmpi:
modules:
intelmpi@2017.1.132%intel@17.0.1: intelmpi/2017--binary
buildable: False
cmake:
modules:
cmake@3.5.2: cmake/3.5.2
buildable: False
netlib-scalapack:
modules:
netlib-scalapack@2.0.2^intelmpi: scalapack/2.0.2--intelmpi--2017--binary
netlib-scalapack@2.0.2^openmpi: scalapack/2.0.2--openmpi--1-10.3--intel--pe-xe-2017--binary
buildable: False
openblas:
modules:
openblas@3.6.0%gcc@6.1.0: blas/3.6.0--gnu--6.1.0
buildable: False
intel-mkl:
modules:
intel-mkl@2017.1.132%intel: mkl/2017--binary
buildable: False
bison:
paths:
bison@2.7: /usr/bin/bison
buildable: False
flex:
paths:
flex@2.5.37: /usr/bin/flex
buildable: False
zlib:
modules:
zlib@1.2.8%gcc@6.1.0: zlib/1.2.8--gnu--6.1.0
buildable: False
hwloc:
modules:
hwloc@1.11.3: hwloc/1.11.3--gnu--6.1.0
buildable: False
all:
providers:
mpi: [openmpi, intelmpi]I'm running into some unrelated issues with the scotch package that I'll create a separate report for. |
|
Thanks, very useful info, keep us updated. Which speck an compiler.yaml are you using? so maybe we can exercise and eventual PR in identical conditions as yours |
|
|
|
Capturing modulecmd is not quite as simple as @luigi-calori suggested, because sometimes modulecmd is not in the path on systems that use an executable instead of a tcl script. The solution needs to read the shell environment to determine what that system executes when a user types Unless anyone objects, I'm pursuing a solution that involves parsing @Exteris your environment appears to be csh. Is bash present on your machines, and if so am I correct in assuming that the output for |
|
Hi All, thanks for looking into this for me (I was the user who 'reported' it to Todd) I'm very new to Spack, all this help and advice is most welcome. @becker33 - we use bash - and yes, typeset -f includes an eval line similar: module ()
{
eval `/aaa/Modules/bin/modulecmd.tcl sh $*`
} |
A user reported this error.
It looks like
load_moduleinbuild_enviroment.pywill fail ifmodulecmdis not available.@alalazo: Is it supposed to be possible to get to this code if the system supports modules? Seems like we should check for
modulecmdup front. I haven't dug into this yet.The text was updated successfully, but these errors were encountered: