Имя библиотеки libssl.so.0.9.8k не обнаруживается софтом распространяемым в бинарном виде. Обычно ищется libssl.so.0.9.8 и так принято в большинстве других дистрибутивов, например Mandriva и SuSE. Обнаружено на OPC UA клиенте uaexpert-bin-linux32-x86-gcc4.1.2-r5625.tar.gz
(В ответ на комментарий №0) > Имя библиотеки libssl.so.0.9.8k не обнаруживается софтом распространяемым в > бинарном виде. Сонеймы библиотек из пакета libssl7 выглядят как libssl.so.7 и libssl.so.8. > Обычно ищется libssl.so.0.9.8 Нет. Обычно ищется какой-то другой сонейм. > и так принято в большинстве других дистрибутивов, например Mandriva и SuSE. Это NOTABUG. Если вам нужен libssl с сонеймом, которого нет в ALT, открывайте баг с просьбой собрать нужную версию.
(In reply to comment #1) > (В ответ на комментарий №0) > > Имя библиотеки libssl.so.0.9.8k не обнаруживается софтом распространяемым в > > бинарном виде. > Сонеймы библиотек из пакета libssl7 выглядят как libssl.so.7 и libssl.so.8. И у остальных дистрибютеров тоже? > > Обычно ищется libssl.so.0.9.8 > Нет. Обычно ищется какой-то другой сонейм. Да ну? [root@roman lib]# [root@roman uaexpert]# ./uaexpert ./uaexpert: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory > > и так принято в большинстве других дистрибутивов, например Mandriva и SuSE. > Это NOTABUG. Если вам нужен libssl с сонеймом, которого нет в ALT, открывайте > баг с просьбой собрать нужную версию. В Mandriva и SuSE это вообще не баг, потому как его там нет. Почему бы линк хотя-бы не создавать, для совместимости?
(В ответ на комментарий №2) > (In reply to comment #1) > > (В ответ на комментарий №0) > > > Имя библиотеки libssl.so.0.9.8k не обнаруживается софтом распространяемым > > > в бинарном виде. > > Сонеймы библиотек из пакета libssl7 выглядят как libssl.so.7 и libssl.so.8. > И у остальных дистрибютеров тоже? > Да, у нас есть совместимость с Fedora. Там сделано именно так... Причём, ещё зимой, они резко сменили soname с 7 на 8. Для совместимости, мы сейчас держим оба. > > > Обычно ищется libssl.so.0.9.8 > > Нет. Обычно ищется какой-то другой сонейм. > Да ну? > [root@roman lib]# [root@roman uaexpert]# ./uaexpert > ./uaexpert: error while loading shared libraries: libssl.so.0.9.8: cannot open > shared object file: No such file or directory > Вы откуда взяли этот бинарник? На каком дистрибутиве его собирали? С этого стоило начать. Поскольку собирался он точно не у нас и не в Федоре, например... > > > и так принято в большинстве других дистрибутивов, например Mandriva и > > > SuSE. > > Это NOTABUG. Если вам нужен libssl с сонеймом, которого нет в ALT, > > открывайте баг с просьбой собрать нужную версию. > В Mandriva и SuSE это вообще не баг, потому как его там нет. Почему бы линк > хотя-бы не создавать, для совместимости? Потому, что вы вопрос поставили не правильно... Вместо просьбы сделать такой симлинк по такой-то причине, вы стали искать изъян. А его нет... Нет такого изъяна. Есть разные решения одной задачи. У вас же возник вопрос с поддержкой бинарников для других систем. В полной мере такая поддержка не осуществима. Дело в том, что разные сборке 0.9.8 (например, 0.9.8d и 0.9.8h) бинарно не совместимы - у них ABI разное. И начинать вопрос с того, что что-то не так, не разобравшись в задаче, по-крайней мере, не аккуратно. В общем я подумаю над этой симлинкой... А вы, если готовы поучаствовать в решении этой "баги" активно, пожалуйста, сделайте этот симлинк руками и проверьте ваши приложения в таком виде... Они с нашим libssl7, который libssl8, работать-то будут нормально?
(In reply to comment #3) > Да, у нас есть совместимость с Fedora. Там сделано именно так... Причём, ещё > зимой, они резко сменили soname с 7 на 8. Для совместимости, мы сейчас держим > оба. Понятно. > Вы откуда взяли этот бинарник? На каком дистрибутиве его собирали? Скачал у производителя. На каком дистре они не указали. Это коммерческая, однако бесплатная, софтина доступная без исходников в установщике *.run здесь: www.unified-automation.com. > > > > и так принято в большинстве других дистрибутивов, например Mandriva и > > > > SuSE. > > > Это NOTABUG. Если вам нужен libssl с сонеймом, которого нет в ALT, > > > открывайте баг с просьбой собрать нужную версию. > > В Mandriva и SuSE это вообще не баг, потому как его там нет. Почему бы линк > > хотя-бы не создавать, для совместимости? > > Потому, что вы вопрос поставили не правильно... Вместо просьбы сделать такой > симлинк по такой-то причине, вы стали искать изъян. А его нет... Нет такого > изъяна. Есть разные решения одной задачи. Симлинк я поставил сразу. И оно прошло, правда не далеко и споткнулось на libpng. > И начинать вопрос с того, что что-то не так, не разобравшись в задаче, > по-крайней мере, не аккуратно. Я то понимаю эти проблемы. А вот если абсолютный новичёк, но автоматчик работающий с вендой, качнёт с такого сайта софтину и не запустит её, то в систему автоматизации такой дистр просто не попадёт. :) > В общем я подумаю над этой симлинкой... А вы, если готовы поучаствовать в > решении этой "баги" активно, пожалуйста, сделайте этот симлинк руками и > проверьте ваши приложения в таком виде... Они с нашим libssl7, который libssl8, > работать-то будут нормально? OK. Как только решится проблема с: version PNG12_0 not defined in file libpng12.so.0 with link time reference
(В ответ на комментарий №4) > (In reply to comment #3) [...] > > В общем я подумаю над этой симлинкой... А вы, если готовы поучаствовать в > > решении этой "баги" активно, пожалуйста, сделайте этот симлинк руками и > > проверьте ваши приложения в таком виде... Они с нашим libssl7, который libssl8, > > работать-то будут нормально? > OK. Как только решится проблема с: > version PNG12_0 not defined in file > libpng12.so.0 with link time reference Попробуйте так, как делаю я... Сделайте в каталоге с прогой симлинку libpng12.so.0 -> /usr/lib/libpng.so.3 и попробуйте запустить, с укзанием дополнительного каталога загрузки библиотек: LD_LIBRARY_PATH=КАТАЛОГ_С_СИМЛИНКОЙ ВАША_ПРОГА
Не работает: [root@roman uaexpert]# ls -l total 3619 lrwxrwxrwx 1 root root 20 Jun 23 17:10 libpng12.so.0 -> /usr/lib/libpng.so.3 -rw-r--r-- 1 root root 917099 Apr 24 12:50 libuabase.so -rw-r--r-- 1 root root 550417 Apr 24 12:51 libuaclient.so -rw-r--r-- 1 root root 47869 Apr 24 12:50 libuapki.so -rw-r--r-- 1 root root 869410 Apr 24 12:49 libuastack.so drwxr-xr-x 2 root root 280 Apr 24 12:58 plugins -rw-r--r-- 1 root root 1057 Apr 24 12:48 tips_en.txt -rwxr-sr-x 1 root uaexpert 1304544 Apr 24 12:58 uaexpert drwxr-xr-x 3 root root 368 Apr 24 12:48 xdg [root@roman uaexpert]# LD_LIBRARY_PATH=/opt/unifiedautomation/uaexpert ./uaexpert ./uaexpert: relocation error: /opt/unifiedautomation/qt-4.4.1/lib/libQtGui.so.4: symbol png_create_read_struct, version PNG12_0 not defined in file libpng12.so.0 with link time reference
(В ответ на комментарий №6) > Не работает: И не должно. И не обсуждайте одну проблему в баге про совершенно другую.
Бросил линк libssl.so.0.9.8 -> libssl.so.0.9.8d Полёт нормальный.
(В ответ на комментарий №8) > Бросил линк libssl.so.0.9.8 -> libssl.so.0.9.8d > Полёт нормальный. В каком бранче? Похоже на 4.1. Как я уже пытался объяснить, libssl.so.0.9.8d из 4.1 и libssl.so.0.9.8k из 5.0 бинарно не совместимы. То есть на libssl.so.0.9.8 -> libssl.so.0.9.8d оно может и работает, а на libssl.so.0.9.8 -> libssl.so.0.9.8k уже не будет. В принципе, оно может работать и там, и там... Но где-нибудь оно может рухнуть в любой момент.
> В общем я подумаю над этой симлинкой... А вы, если готовы поучаствовать в > решении этой "баги" активно, пожалуйста, сделайте этот симлинк руками и > проверьте ваши приложения в таком виде... Они с нашим libssl7, который libssl8, > работать-то будут нормально? Линк: libssl.so.0.9.8 -> libssl.so.0.9.8k Полёт нормальный.
В OpenSuSE под soname libssl.so.0.9.8 идёт libssl.so.0.9.8h.
Кстати, всё сказанное касается и libcrypto.so.0.9.8.
В сизифе этот линк добавлен. Вероятно стоит его добавить и в бранчах. По крайней мере в 5.1
Этот баг закрыть не стоит ли, как устаревший ?
(В ответ на комментарий №14) > Этот баг закрыть не стоит ли, как устаревший ? Стоит. Закрываю.
