Apparently, the Core packages are getting precedence over the module paths added by loading the toolchain.
#23579
and
some discussions in slack as well.
I asked @xdelaruelle to dig into what he saw when he was testing modules and reports:
FAILED: Installation ended unsuccessfully: Module command '/usr/share/Modules/libexec/modulecmd.tcl python load OpenFOAM/6-20190620' failed with exit code 1; stderr:
Loading ncurses/6.3
ERROR: Conflicting ncurses/6.4 is loaded
Loading gettext/0.21.1
ERROR: Load of requirement ncurses/6.3 failed
Loading GLib/2.77.1
ERROR: Load of requirement gettext/0.21.1 failed
Loading cairo/1.17.8
ERROR: Load of requirement GLib/2.77.1 failed
Loading gnuplot/5.4.8
ERROR: Load of requirement cairo/1.17.8 failed
Loading OpenFOAM/6-20190620
ERROR: Load of requirement gnuplot/5.4.8 failed
It seems that somehow Core modulepath gets higher predecence at some point and gettext/0.21.1 is loaded from there
os.environ['MODULEPATH'] = ' # (I split the lines here for readability)
/home/xa/.local/easybuild/modules/all/Core:
/tmp/eb-vtt7utkh/tmpezn8j4a9/all/MPI/GCC/12.3.0/OpenMPI/4.1.5:
/home/xa/.local/easybuild/modules/all/Compiler/LLVM/16.0.6:
/home/xa/.local/easybuild/modules/all/MPI/GCC/12.3.0/OpenMPI/4.1.5:
/home/xa/.local/easybuild/modules/all/Compiler/GCC/12.3.0:
/home/xa/.local/easybuild/modules/all/Compiler/GCCcore/12.3.0:
/home/xa/.local/easybuild/modules/all:
/usr/share/Modules/modulefiles:
/etc/modulefiles:
/usr/share/modulefiles'
It happens only with HMNS due to names being ambiguous between Core and toolchain levels, and the problem only reveals itself in rare situations like this; since the SYSTEM level gettext was using an older ncurses.
The problem isn't that ncurses mismatches, the problem is that the gettext from Core is taking precendence; we want the one from the GCCcore level to be loaded here no matter what.
So, I'm hesitant to "fix" the issue by changing the ncurses version in SYSTEM level gettext; we should never try loading that to begin with.
Apparently, the
Corepackages are getting precedence over the module paths added by loading the toolchain.#23579
and
some discussions in slack as well.
I asked @xdelaruelle to dig into what he saw when he was testing modules and reports:
It happens only with HMNS due to names being ambiguous between Core and toolchain levels, and the problem only reveals itself in rare situations like this; since the SYSTEM level gettext was using an older ncurses.
The problem isn't that ncurses mismatches, the problem is that the gettext from Core is taking precendence; we want the one from the GCCcore level to be loaded here no matter what.
So, I'm hesitant to "fix" the issue by changing the ncurses version in SYSTEM level gettext; we should never try loading that to begin with.