On Fri, 7 Nov 2014, Artem Chuprina wrote:
Artem Chuprina -> [email protected] @ Fri, 07 Nov 2014 11:31:31
+0300:
AC> /opt/ghc/7.8.3/bin/ghc --version
AC> /opt/ghc/7.8.3/lib/ghc-7.8.3/bin/ghc: error while loading shared libraries:
libHShaskeline-0.7.1.2-ghc7.8.3.so: cannot open shared object file: No such file
or directory
AC> при этом
AC> ldd /opt/ghc/7.8.3/lib/ghc-7.8.3/bin/ghc|grep
libHShaskeline-0.7.1.2-ghc7.8.3.so
AC> libHShaskeline-0.7.1.2-ghc7.8.3.so =>
/opt/ghc/7.8.3/lib/ghc-7.8.3/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.3.so
(0x00007ff10b2c1000)
Дополнительное расследование (запуск того и другого в окружении
LD_DEBUG=libs,files) показало, что при ldd ld.so смотрит на RPATH из
бинарника, а при запуске - нет. Опять же, гугл на эту тему ничего
вразумительного не рассказывает...
Вообще то ldd это просто bash-скрипт вокруг ld-linux.so
Все что он делает сводится к конструкции типа
LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 executable
Ситуация с RPATH еще больше запутывает дело. Как при запуске
проигнорировать rpath не очень понятно. Хотя... можно попробовать скажем
LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 --inhibit-rpath "" executable
Возможно, приемлемым решением будет очистить rpath и управлять только
с помощью LD_LIBRARY_PATH.
В дебиане есть удобная программка chrpath
С помощью нее можно посмотреть (-l) и очистить (-d) rpath в executable.
Ю.
p.s. https://wiki.debian.org/RpathIssue
