【问题标题】:How to set the USIF specific variable "GLIBC" in modulefile?如何在模块文件中设置 USIF 特定变量“GLIBC”?
【发布时间】:2020-09-29 09:17:50
【问题描述】:

我在一个基于 slurm 的 HPC 集群中工作,过去 5 年我一直这样做。我们加载和卸载分析所需的模块,其中编译器如gcc。直到两天前,这对我来说一直是无缝的。在过去的两天里,每次我尝试加载任何模块时,都会收到此错误:

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

互联网没有任何帮助,因为似乎没有任何关于这个已经问过/解决的问题。系统管理员目前没有回复我的邮件,因此我的工作完全停止了。

我已尝试从另一台计算机和另一个帐户挂载/卸载模块,并且工作正常,因此问题与我的帐户有关。

这里有没有人有过这个问题的经验?如果是这样,什么可能已经开始呢?我什至不知道从哪里开始寻找,或者是什么导致了这种情况,因为我们没有安装自己的编译器。

编辑#1:

对于它的价值(不确定)我的$LD_LIBRARY_PATH 看起来像这样:

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

一开始我有点怀疑:。是否缺少第一个组件?这个变量我没碰过。

编辑#2:

经过其他一些挖掘,并将我的环境与一位对此没有问题的同事进行比较,我发现我的env 中缺少以下三个变量:

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

我还发现$CPATH: 开头,就像$LD_LIBRARY_PATH,而他的$CPATH 没有:

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

我尝试export ... 他们,但没有帮助。但是,这让我觉得有一个更深层次的问题。

编辑#3:

按照下面 cmets 中的要求,我已经完成module show gcc/5.3 以查看实际的模块文件。内容如下:

#%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}

【问题讨论】:

  • 查看您尝试加载的模块文件的内容将有助于确定您收到此类错误消息的原因
  • @XavierDelaruelle 我认为我无权访问它,因为这应该需要 root 权限(我认为)。
  • 执行module show gcc 将为您提供存储模块文件的路径,然后您应该能够读取该文件
  • @XavierDelaruelle 我用module show gcc/5.3的内容编辑了问题

标签: gcc glibc hpc slurm modulefile


【解决方案1】:

我们与 HPC 集群的系统管理员一起解决了这个问题。这真是一件愚蠢的事情,我发布答案只是为了让遇到相同问题的其他人直接知道在哪里寻找,而不会浪费几天的试验和错误。

问题源于$PATH。虽然在某些情况下您可能希望通过执行PATH=/my/extra/path/directory:${PATH} 来更新$PATH 变量,但在这种情况下,我必须将额外路径放在最后,如PATH=${PATH}:/my/extra/path/directory

直到两天前,这才成为问题,五年来一直运行良好。也许他们在系统管理员方面进行了一些更改,因此在我的$PATH 中找不到所需的可执行文件。

我查过,我是我的同事中唯一一个在.bashrc 中有修改的$PATH。这可以解释为什么只有我有这个问题。

无论如何,如果您正在阅读本文并且遇到了同样的问题,那么您就知道该去哪里找了。

【讨论】:

    猜你喜欢
    • 2020-07-16
    • 2017-09-08
    • 2012-09-02
    • 1970-01-01
    • 1970-01-01
    • 2020-01-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多