【问题1】

/usr/bin/ld: error while loading shared libraries: libbfd-2.27-44.base.el7_9.1.so: cannot open shared object file: No such file or directory

【根因分析】

已知这是在openeuler22.03sp1操作系统上进行编译的过程，出现的提示libbdf.**.el7_9.1so为centos的操作系统动态库。因为这个singularity容器是在宿主机为centos7的操作系统下起的，导致ld链接编辑程序继承了宿主机。

【解决方案】

由于项目要求，选择放弃使用该沙箱，寻找宿主机同为openeuler22.03sp1再起个沙箱进行部署即可解决。

tips：在使用沙箱做软件部署验证时，尽量确保宿主机操作系统跟容器的操作系统一致，通过执行命令ldd /usr/bin/ld查看，结果不出现链接库Not found字样即代表ld正常。

【问题2】

/usr/bin/ld:cannot find -ljpeg

【根因分析】

这是在迁移软件过程中常见的一个提示，无法找到相应链接库。一般可通过说明 export LDFLAGS="-L/path/to/xx/lib -lxx"解决，但有许多应用构建过程中严格按makefile进行编译，此刻便需要对其makefile进行修改。

【解决方案】

由于此应用依赖makearps进行构建，我们按需修改，在makearps的第1636行，-ljpeg前添加当前环境下的库文件路径。

【问题3】

undefined reference to `xdr_*===》提示多处未定义引用xdr_*

【根因分析】

调用hdf4的libmdhdf.a，无法寻找到相关库==》-ltirpc（即使tirpc库的路径为/usr/lib64）。

【解决方案】

在makearps的第1636行，-ljpeg后添加libtirpc库文件路径和-ltirpc标识。

编译成功==》

tips：对于未定义引用类问题，应理清其链接（依赖）关系，这里是hdf对于libtirpc的链接需求报错，并非arps主程序对hdf4链接需求（手动编译的hdf与yum安装的不一致，不可混淆。当大型应用的依赖有hdf且使用源码编译的hdf时，应顺带添加libtirpc的路径，避免编译报错）。

【END】

参考社区指南为https://www.hikunpeng.com/document/detail/zh/kunpenghpcs/prtg-osc/kunpengarps_02_0007.html

需要说明：

①vi命令修改文件--快速删除文件的注释内容操作错误。正确应无需按“i”进入编辑模式。

②对删除的注释行数存在错误，如：

src/arps/module_precision.f90的前35行，实际还需再多删除7行左右。

src/arps/module_mp_wsm6.f90的前35行，实际还需多删除7行左右。