Hi Valeriu,
On 19/11/14 14:27, Valeriu Codreanu wrote:
Hi Fotis, Kenneth, Pablo,
Thanks for all your suggestions. I have finally managed to get EasyBuild
installed and loaded. It was indeed a problem related to the two module
environments that were conflicting.
However, when I try to build the WRF package I get this error:
valeriuc@login3:~$ eb WRF-3.5.1-goolf-1.4.10-dmpar.eb -Dr
== temporary log file in case of crash
/scratch/easybuild-l0Rfu9/easybuild-7kKi7g.log
ERROR: EasyBuild crashed with an error (at
easybuild/software/EasyBuild/1.15.2/lib/python2.6/site-packages/easybuild_f
ramework-1.15.2-py2.6.egg/easybuild/tools/modules.py:541 in run_module):
homkat(4):ERROR:154: Version symbol 'default' loops
We have a module homkat installed on the system but it is not loaded or
used when calling eb. If I try to do: module load homkat, I hit exactly
the same error (homkat(4):ERROR:154).
Do you have any suggestion for how to tackle this?
I am also attaching the complete log file.
Hmm, that's very weird... Are you also seeing this problem if you're
running a "module avail"?
Can you enable the --debug (or -d) command line option, and send us the
debug log? I'm missing some info with a regular log to really tell
what's going on.
Also: are you actually interested in WRF as an application? If not, I'd
suggest trying to build another application instead (the build should
work, but you may as well build something you care about).
In any case, you'll need to get EasyBuild to build & install a toolchain
(e.g., goolf) first, which will be done as a part of "eb WRF...eb
--robot", so it doesn't hurt.
regards,
Kenneth
Best wishes,
Valeriu
On 19/11/14 10:45, "Fotis Georgatos" <[email protected]> wrote:
Hi Valeriu, Kenneth,
On Nov 18, 2014, at 9:35 PM, Kenneth Hoste <[email protected]> wrote:
It may have something to do with the modules being loaded with the old
modulecmd binary (v3.1.6), and then manipulating/querying the state with
the latest version 3.2.10.
Or, perhaps there is something that tickles environment variables
LOADEDMODULES and _LMFILES_;
I¹d suspect either shell init files or, fancy hooks living inside
modulefiles themselves.
I'd suggest a clean-fresh build of modulecmd, visible by a very
restricted $PATH,
if possible, done from a new clean account. That may help in differential
debugging.
cheers,
F.
--
echo "sysadmin know better bash than english" | sed s/min/mins/ \
| sed 's/better bash/bash better/' # signal detected in a CERN forum
