How to set the USIF specific variable "GLIBC" in modulefile?

Question

I am working in a slurm-based HPC cluster, and I have done so for the past 5 years. We load and unload the modules we need for our analyses, among which the compilers such as gcc . This has worked seamlessly for me until two days ago. For the last two days, each time I try to load any module, I get this error:

Couldn't set USIF specific variable "GLIBC" in modulefile - please contact
 system administration! (Refer to UMEA register_USIF.sh utility.)

The internet has been no help, as there seems to be nothing about this already asked / solved. The sysadmin is currently not replying to my mail so my work is completely stopped due to this.

I have tried to mount / unmount modules from another computer and another account and it works fine, so the issue is bound to my account.

Does anyone here have any previous experience with this issue? If so, what is likely to have started it? I don't even know where to start looking, or what could have caused this, since we don't install our own compilers.

Edit #1:

For what it's worth (not sure) my $LD_LIBRARY_PATH looks like this:

LD_LIBRARY_PATH=:/cm/shared/apps/slurm/current/lib:/cm/shared/apps/slurm/current/lib/slurm

I am a bit suspicious of that : in the beginning. Is there a first component missing? I have not touched this variable.

Edit #2:

After some other digging, and comparing my environment with the one of a colleague that has no issues with this, I found that the following three variables are missing from my env :

UMEA_HOME=/opt/sw/UMEA/current
UMEA_INCLUDE=/opt/sw/UMEA/current/include
UMEA_CONFIG=/opt/sw/UMEA/current/config

And I also found out that the $CPATH begins with a : like the $LD_LIBRARY_PATH , while his $CPATH doesn't:

CPATH=:/cm/shared/apps/slurm/current/include

I tried to export ... them but it hasn't helped. However, it makes me think that there is a deeper problem.

Edit #3:

As requested below in the comments, I have done module show gcc/5.3 to see the actual module file. Here is the content:

#%Module######################################################################
##

source $env(UMEA_INCLUDE)/vsc_include.tcl
source $env(UMEA_INCLUDE)/common_include.tcl
source $env(UMEA_INCLUDE)/prereq_include.tcl

set verbosity 0
set_versions 
set base_path  [ load_unload ]
set_paths $base_path $module_name
set_version_number 2

setenv CC gcc
setenv CXX g++
setenv FC gfortran
setenv F77 gfortran
setenv F90 f95
setenv GDB gdb
setenv VSC_COMPILER_NAME ${module_name}
setenv VSC_COMPILER_VERSION ${module_version}

Answer 1

Together with the sysadmin of the HPC cluster we have solved it. It was really a stupid thing and I'm posting the answer just so that someone else has the same issue knows straight where to look for, without losing days of trials and errors.

The issue derives from the $PATH . While in some cases you may want to update the $PATH variable by doing PATH=/my/extra/path/directory:${PATH} , in this case I had to put my extra paths at the end, as in PATH=${PATH}:/my/extra/path/directory .

This was never an issue until two days ago, for five years it has worked fine. Perhaps they have changed something on the sysadmin side, so that a needed executable was not found anymore in my $PATH .

I checked, and I'm the only one of my colleagues that has a modified $PATH in the .bashrc . That would explain why only I was having the issue.

Anyway, if you're reading this and you had the same issue, you know where to look.