Почему бы игнорировать беговую дорожку? - PullRequest
0 голосов
/ 13 ноября 2018

На 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 app -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

1 Ответ

0 голосов
/ 14 февраля 2019

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

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

...