Почему бы игнорировать беговую дорожку?

На CentOS 7.2 я создал приложение с g++ 4.8.5, которое не может работать, потому что не может найти библиотеку, которая существует в его runpath, Я почти уверен, что это сработало две недели назад. Что может вызвать это?

$ ./app
./app: error while loading shared libraries: libhdf5.so.9: cannot open shared object file: No such file or directory

$ ldd ./app | grep libhdf5
    libhdf5.so.9 => not found

$ readelf fotalg_test_unit -d | grep path
 0x000000000000001d (RUNPATH)            Library runpath: [/opt/ProductName/lib:/opt/ProductName/lib/private]

$ ll /opt/ProductName/lib/libhdf5.so*
lrwxrwxrwx. 1 fotechd fotechd      16 Oct 26 14:38 /opt/ProductName/lib/libhdf5.so -> libhdf5.so.9.0.0
lrwxrwxrwx. 1 fotechd fotechd      16 Oct 26 14:38 /opt/ProductName/lib/libhdf5.so.9 -> libhdf5.so.9.0.0
-rwxr-xr-x. 1 fotechd fotechd 3316074 Oct 26 14:35 /opt/ProductName/lib/libhdf5.so.9.0.0

настройка LD_LIBRARY_PATH исправляет это временно:

$ LD_LIBRARY_PATH=/opt/ProductName/lib ./app
...
OK
Источник

0 ответов

Я смог решить эту проблему на моей стороне. Для меня это было потому, что не найденная библиотека была косвенной и runpath на самом деле не разрешает косвенные зависимости. Я исправил это с помощью rpath вместо runpath передавая дополнительный -Wl,--disable-new-dtags опция компоновщика для компилятора.

Здесь есть хорошее и подробное объяснение: как установить RPATH и RUNPATH с GCC/LD?

Источник

Чтобы найти общие объекты, dlopen() выполняет поиск в следующем порядке:

  • путь поиска библиотеки времени выполнения, который был установлен с помощью параметра -rpath для ld (см. Справочник по утилитам), когда двоичный файл был связан
  • каталоги, указанные в переменной среды LD_LIBRARY_PATH
  • каталоги, указанные в строке конфигурации _CS_LIBPATH

Это выглядит dlopen() не проверяет RUNPATH.

http://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.doc.neutrino_lib_ref/d/dlopen.html

Источник
Другие вопросы по тегам