Может быть это очевидная вещь, а может и нет, но, в первый раз столкнувшись с этим, я провел много часов за компьютером, чтобы исправить эту ошибку.
Итак, очень часто бывает, что после установки программы, при ее запуске выскакивает вот такая ошибка:
error while loading shared libraries: lib.so: cannot open shared object file: No such file or directory
Чтобы точно удостовериться в чем тут дело, нужно проверить, правильно ли прилинковались нужные динамические библиотеки к нашей программе в процессе сборки. Сделать это нам поможет команда ldd. Пишем, например:
[root@tisnum-head1 PH]# ldd ph.x
linux-vdso.so.1 => (0x00007fffe2600000)
libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x000000376f400000)
libmpi_f90.so.1 => not found
libmpi_f77.so.1 => not found
libmpi.so.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00000030c7e00000)
libm.so.6 => /lib64/libm.so.6 (0x00000030c8a00000)
librt.so.1 => /lib64/librt.so.1 (0x00000030c8e00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003d2c800000)
libutil.so.1 => /lib64/libutil.so.1 (0x00000030d7200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030c8600000)
libc.so.6 => /lib64/libc.so.6 (0x00000030c8200000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000030d3200000)
/lib64/ld-linux-x86-64.so.2 (0x00000030c7a00000)
Итак, очень часто бывает, что после установки программы, при ее запуске выскакивает вот такая ошибка:
error while loading shared libraries: lib.so: cannot open shared object file: No such file or directory
Чтобы точно удостовериться в чем тут дело, нужно проверить, правильно ли прилинковались нужные динамические библиотеки к нашей программе в процессе сборки. Сделать это нам поможет команда ldd. Пишем, например:
[root@tisnum-head1 PH]# ldd ph.x
linux-vdso.so.1 => (0x00007fffe2600000)
libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x000000376f400000)
libmpi_f90.so.1 => not found
libmpi_f77.so.1 => not found
libmpi.so.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00000030c7e00000)
libm.so.6 => /lib64/libm.so.6 (0x00000030c8a00000)
librt.so.1 => /lib64/librt.so.1 (0x00000030c8e00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003d2c800000)
libutil.so.1 => /lib64/libutil.so.1 (0x00000030d7200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030c8600000)
libc.so.6 => /lib64/libc.so.6 (0x00000030c8200000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000030d3200000)
/lib64/ld-linux-x86-64.so.2 (0x00000030c7a00000)
Видим, что библиотеки libmpi_f90.so.1, libmpi_f77.so.1 и libmpi.so.1 не найдены. В данном случае проблема состоит в том, что программа была собрана в окружении OpenMPI, а сейчас стоит окружение IntelMPI. и
Если же мы видим, что пути ко всем библиотекам найдены, но при запуске по-прежнему выскакивает эта ошибка, то стоит проверить прописаны ли пути к этим библиотекам на узлах кластера (!). На узлах доступа пути к библиотекам могут быть прописаны, но на вычислительных узлах это может быть и не сделано, а т.к. расчет ведется именно на вычислительных узлах, то запуску мешает отсутствие правильно прописанных путей к этим библиотекам.
Решаем эту проблему. Заходим на вычислительный узел, и проверяем, есть ли данная библиотека в списке:
ldgonfig -p | grep lib.so
Если на данный запрос ничего не выдалось, значит ее там нет. После этого ищем местонахождения библиотеки:
locate lib.so
или
find / -name lib.so
Какой-то из этих вариантов должен сработать.
После того, как мы нашли местонахождения, его нужно записать в линкер, а именно, в папке /etc/ld.so.conf.d/ лежат файлы типа
atlas-x86_64.conf
intel64.conf
В которых содержатся пути к библиотекам. Можно создать свой файл, например, mylibs.conf и написать в нем строку где будет указан путь к библиотеке lib.so
/opt/libs/
сохраняем его и перезапускаем службу ldconfig, набрав в командной строке
ldconfig
После этого проверяем, создались ли необходимые ссылки на нашу библиотеку или нет
$ ldconfig -p | grep lib.so
lib.so (libc6,x86-64) => /opt/libs/lib.so
После этого можно смело запускать программу и все будет работать, не забудьте все тоже самое сделать на остальных вычислительных узлах.
Комментариев нет:
Отправить комментарий