LINUX.ORG.RU

зависимости приложения

 , ,


0

2

Здравствуйте. Пишу приложение на с++, которое использует openssl и libcrypto. На системе, на которой происходит сборка, установлена openssl0.9.8 на системе, на которой запускаю приложение - openssl1.0.0. Проблема в том, что пока я не создам симлинк на libssl1.0.0 приложение не запускается. Что я делаю не так?

Ответ на: комментарий от HighwayStar

там мэйкфайл достаточно здоровый. есть может какие-то правила для соответствия версий?

LetMeFun ()

С openssl дела не имел, но у тебя major версия разная у библиотек. Если это так, то оно и не должно работать.

nanoolinux ★★★★ ()

Что я делаю не так?

Все. Собирать нужно на target-системе, если хочешь бинарник поставлять.

kulti ★★ ()
Ответ на: комментарий от LetMeFun

Обычно это первая цифра в версии. Но у некоторых шибко умных типа libpng это по другому.

nanoolinux ★★★★ ()

Утраиваю сборку на целевой платформе/системе.

Deleted ()

Что я делаю не так?

Собираешь не в целевом окружении. В чём проблема собирать в виртуалке или хотя бы в chroot с установленными как на целевой системе библиотеками?

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

проблема в том, что целевое окружение может быть не одно и приложение должно работать на каждом. да, забыл упомянуть. с 32 битной версией почему-то всё ок. проблема при сборке 64 битной

LetMeFun ()
Ответ на: комментарий от LetMeFun

Что за бред? Поднять виртуалку с целевой системой и собирать там религия не позволяет?

kulti ★★ ()
Ответ на: комментарий от LetMeFun

Тогда три варианта:

1. Линкуйся статически (хотя в случае openssl не уверен, что это пройдет)

2. Таскай библиотеки с собой

3. Собирай подо все целевые платформы

kulti ★★ ()
Последнее исправление: kulti (всего исправлений: 1)

наверное при сборке линковщик привязывается к конкретной версии, надо чтобы в зависимостях были libssl.so и libcrypto.so без указания версии. Работать приложение будет, ибо обратная совместимость между версиями есть

приведи выхлоп ldd <бинарник твоего приложения> на системе, где openssl1.0.0

Harald ★★★★★ ()
Ответ на: комментарий от kulti

Ко мне придёт клиет и скажет: «я хочу купить твоё ПО». А я ему такой: «А у вас redhat или suse? и какой openssl у вас установлен?» так вы себе представляете?

LetMeFun ()
Ответ на: комментарий от Harald

*** libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x0000003943800000) *** libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x000000393f800000) *** libnetsnmp.so.15 => /usr/lib64/libnetsnmp.so.15 (0x0000003509200000) **** Это те с которыми проблемы

LetMeFun ()
Ответ на: комментарий от LetMeFun

libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8

как я и предполагал. Сборка случаем не с участием libtool происходит?

Harald ★★★★★ ()
Ответ на: комментарий от LetMeFun

хотя я кажется туплю, правильнее всё-таки под каждый дистр с разными версиями openssl свой пакет делать

Harald ★★★★★ ()
Ответ на: комментарий от LetMeFun

проблема в том, что целевое окружение может быть не одно и приложение должно работать на каждом

И что? Сделай 10 виртуалок. Тестировать-то тебе всё равно придётся в каждом возможном окружении.

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

ясно короче. аналогичная ситуация : я спарашиваю как доехать до Москвы, а мне все упорно говорят, что в москву мне не надо, а надо в Питер. Спасибо

LetMeFun ()
Ответ на: комментарий от LetMeFun

Ко мне придёт клиет и скажет: «я хочу купить твоё ПО». А я ему такой: «А у вас redhat или suse? и какой openssl у вас установлен?» так вы себе представляете?

Самый правильный вариант - собирать dep, rpm пакеты под все целевые платформы с корректно прописанными зависимостями. И да, у клиента придётся спросить какой дистр и какой версии у него стоит. А вдруг у него вообще опенбздя :)

Второй вариант - таскать все нужные либы с собой, но такой вариант ущербен - слишком много разных окружений, под все не сделаешь.

А при первом варианте ты хотя бы будешь точно знать, что твоё приложение работает под дистрами А и Б начиная с такой-то версии.

Зоопарк такой зоопарк

Deleted ()
Ответ на: комментарий от LetMeFun

Аналогичная ситуация - ты спрашиваешь в Москве как тебе пройти пешком во Владивосток, а все советуют купить билет на поезд или на самолёт. Можно пойти пешком, конечно, дело твоё.

Deleted ()

Проще всего, наверное, линковаться статически. На размер особо повлиять не должно, если линкер возьмёт только реально используемые в приложении функции. Таскать рядом библиотеки не очень удобно (если всё же хочеться, то см. что такое -rpath).

xaizek ★★★★★ ()

Линкуйся статически. Со всем кроме libc. Иначе никак, серьезно говорю. Если не собираешься мейнтейнить версию приложения под каждый таргет дистр линукса, конечно.

lovesan ()

Или юзай dlopen, или линкуйся статически, или делай как проприетарщики (см на вмваре, например)

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от LetMeFun

Ко мне придёт клиет и скажет: «я хочу купить твоё ПО». А я ему такой: «А у вас redhat или suse? и какой openssl у вас установлен?» так вы себе представляете?

А так оно именно и бывает. Точнее на оборот. Покупателю говорят, что наше ПО работает на RHEL 5/6, SLES 11 SP2. Сборки под Debian/Ubuntu не делаем. Пример: http://www.ansys.com/Support/Platform Support

AlexVR ★★★★★ ()
Ответ на: комментарий от LetMeFun

Ну а по делу тебе всё правильно сказали. Выбирается набор целевых систем и под КАЖДУЮ делают rpm/deb, которые и распространяют. При этом на ВСЕХ этих целевых системах проводят тесты и говорят: «мы провели тесты на X x.x, Y y.y, Z z.z».

При этом в рамках одного выпуска Linux дистрибутива (Redhat 5, Ubuntu 12.04, ...) мажорные версии основных библиотек как правило не меняются, что и обеспечивает определённую стабильность работы ПО.

AlexVR ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.