Russian Qt Forum

Имеется приложение, которое необходимо запускать в любом дистрибутиве Linux, не зависимо от наличия/версии Qt в системе. В виндах все понятно: там все решается тупым копированием нужных dll'ок в директорию с программой.

Вопрос в том как это сделать в Linux.
Пробовал сделать по принципу, как в винде: запустил ldd. посмотрел, что программа требует для запуска.
Создал директорию lib и скопировал туда нужные файлы:
libQtCore.so.4 
libQtGui.so.4 
libQtNetwork.so.4 
libQtSql.so.4

а для запуска приложения использую LD_LIBRARY_PATH.
Т.е. запускаю программу, использую*.sh файл, где указываю что-то типа этого:

Bash
bindir=`dirname "$me"`
libdir=`cd "${bindir}/lib" ; pwd`
LD_LIBRARY_PATH="${libdir}:${LD_LIBRARY_PATH}"
export LD_LIBRARY_PATH
#exec "${bindir}" ${1+"$@"}
 
prog2run=`"${bindir}/my_application"`
exec $prog2run

Проблема в том, что, помимо Qt-шных библиотек, для запуска приложения необходимы всякие libglib-2.0.so.0, libc.so.6, libgcc_s.so.1 и т.п. И, даже скопировав их в ту же директорию, объявленную в  LD_LIBRARY_PATH, в дистрибутивах с более старой версией библиотек, программа не запускается, ругаясь таким образом:

relocation error: /home/nick/my_application/lib/libglib-2.0.so.0: symbol strncmp, version GLIBC_2.0 not defined in file libc.so.6 with link time reference.

Подскажите, пожалуйста, как решить эту проблему?

Вам по моему, надо скомпилировать Qt, со статическими библиотеками, когда компилитуете Qt, чтоб она была независима от системных библиотек, надо указать следующие ключи:

-release -static -qt-zlib -qt-gif -qt-libmng -qt-libpng -qt-libtiff -qt-libjpeg ...

эти обязательны для получения статической сборки Qt. Я это пробывал и программа пошла на почти всех дистрибутивах, даю вам линк к программе, чтоб вы сами убедились в этом, Только извините, но интерфейс пока только болгарский, но запускается почти на всех дистрибутивах, которые 32 битовые.

http://www.fileden.com/files/2009/12/4/2675571/linux32/Balans32.tar.bz2

Так, между прочим, я компилировал и для Windows, и программа работает без всяких DLL, так что потребителэ, не обязательно иметь у себя в системме Qt

компилировал как static в Ubuntu, но в Redhat ругалась на другую версию Glib!?....пришлось собирать в RedHat!

В том то и весь проблем, с Qt, так сказать всё нормально, и как показали проведёные тесты в Болгарии, на большинстве дистрибутивов запускается без проблем. Но например на Debian sid, при неизвестно каких условий на Ubuntu 10.4, RedHat, ... не запускается, а собрать glibc, как статическую, у меня почему то не получается. У меня дистрибутив Slackware 13.0, и программа скомпилирована на этой дистрибуции.  :(

для себя - проблему запуска на различных дистрибутивах решил - сборкой проекта в родной среде!!! другого, более оптимального способа, не нашел!!!!

Извините но я забыл, вот проблему с Glib, я решил исключая её, это делается с ключом -no-gtkstyle, при компиляции Qt. Я не знаю вам это решение подойдёт или нет, но так в Qt, остаётся только то что зависит от Qt.

а есть ли у кого опыт использования Statifier - http://statifier.sourceforge.net/ ?

спасибо, попробую!

У statifier'a  две основные проблемы:
1. Memory randomization. -  На системах где все адреса меняются от одного запуска программы к другому программа,
созданная с помощью statifier, обычно выводит только одно сообщение: Segmentation fault.

2. Statifier пакует только библиотеки. Но qt-программы кроме библиотек используют еще и файлы конфигурации,
которые говорят откуда и какие библиотеки загружать.

Ermine (http://magicErmine.com) не имеет этих ограничений, но имеет другое - эта программа коммерческая.

дополнительно добавил -no-qlib

попробовал запустить прогу в CentOS и получил след. ошибку:

Собирать желательно на более старой версии glibc. Если собирать на новой, на старой может и не запуститься

так я же в своем проекте не использую Glib и при сборке QT ставлю -no-qlib -no-gtkstyle !? откуда зависимость то появляется?

Видите ли, glib и glibc, разные библиотеки, вторая это системные библиотеки. Раз у вас такая ситуация, то я думаю что в этой дистрибуции, сами системные библиотеки не статические, тогда придётся перекомпилировать и glibc, как статическую. Другого мне в голову не преиходит.

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

Правильно ли я понял? Glibc собрана у меня как shared,а мне ее нужно пересобрать как static? Если да, то у меня возник ряд вопросов:
1 - как это сделать (думую в гугле найду)
2 - что-нибудь нужно будет менять в проекте?например, указывать пути к библиотекам
3 - и не рухнет ли ubuntu после сборки? это же по идее системная библиотека?
4 - и будет ли прога работать в системах с более раннеми версиями glibc?

Может это поможет http://easy-coding.blogspot.com/2009/03/unix.html

Можно попробовать собрать Glibc отдельно от той Glibc  которая установлена в системе. Т.е. вообще "закинуть" готовую static Glibc  в другие директории и т.п. А уже в вашем проекте указать пути к этой static Glibc.  т.е. НЕ трогать shared Glibc системы, а сделать параллельно свою static Glibc. Думаю идея понятна :).
Дык придется пересобирать ВСЮ бубунту тогда :) .  Это уже попахивает LFS или CLFS и т.п. :)
т.е. см. выше что я написал. ИМХО, должно "прокатить"

если удастся статически слинковать ваше приложение с Glibc  - то по идее должно везде работать.

---------
ЗЫ: Как вариант - можно взять сырцы Glibc и просто подключить их *.h и *.cpp/c к вашему проекту...

ЗЫЗЫ: но для этого необходимо собрать статически Glibc, GCC и т.п.  т.к. может быть, что-то понадобится еще. ИМХО.

с glibc тоже есть ньюансы - там используются NSS плагины, и они по-умолчанию всегда shared. Чтобы из сделать static, надо передавать ключ --enable-static-nss при компиляции glibc и добавлять новые библиотеки к компилируемой программе (какие не помню)

И всё равно сделать один бинарник под все дистрибутивы имхо довольно геморно и непонятно зачем.

+1024

например мне нужно, что бы он работал в CentOs и Ubuntu, а не собирать в каждом дистрибутиве отдельно...и к тому же в CentOs Qt 4.2 (другую версию не удалось установить ?!), а в Ubuntu 4.6....и версия проги с qt 4.6 работает лучше - именно поэтому думал собирать в убунту и запускать в CentOs!

на счет геморно - согласен но это сложная задача вот и геморно
очень даже понятно зачем - для удобства - дрова NVidia например очень удобно иметь одним бинарником под все Linux системы

статическая линковка кьют, на сколько я понимаю, похерит условие LGPL о возомжности пользователю заюзать свою версию, так что нужна либо лицензия на кьют, либо наглость =)
нашел тулзу: autopackage (http://autopackage.org/)
минусы:
довольно вялое сообщество, авторы то экзамены сдают, то аврал на работе разгребают, сайт полурабочий, документация не фонтан, брал из свн - GTK|Qt морды не собираются, результирующий бинарник (именно самого приложения, без учета ресурсов) получается в разы больше (при этом, возможно, вышеперчисленное - просто результат моего поверхностного знакомства с сабжем).
плюсы:
берет на себя рутину по обходу проблем с glibc и бинарной совместимостью (про ABI - довольно подробно у них же на сайте), выполняет функции инсталлятора, предоставляет API для повышения "перемещаемости" приложения (чтото вроде QDesktopServices::storageLocation ( StandardLocation type )), проверяет наличие требуемых зависимостей и, при необходимости, позволяет докачать (если нет wget - само скачивает) - кьют с собой тащить не нужно.

на мой взгляд, проект скорее полумертв, чем полужив, да и повозиться нормально - все руки не доходят, но после довольно поверхностного знакомства результат пока радует - сборка из-под open suse 11.2 работает под последней федорой (не помню цифру, вроде 13 - на днях релизнулась), на других дистрах еще не тестировал. если целевые платформы это только линуксы - довольно приятное решение, видимо. если еще и вин/мак - телодвижений надо побольше, но всяко меньше, чем всё делать вручную (тем более не совсем понятно, что здесь входит во "всё").

зы. про "непонятно зачем" - народ наверное имеет ввиду, что можно распространять в исходниках, мол, "проприетарные поделки" никому тут нафиг не сдались =)

но ведь дрова NVidia - НЕ один бинарник под все Linux системы. Внутри архива хранятся предкомпилированные модули для определённых ядер (отчего архив имеет такой конский размер). Если предкомпилированные модули не подходят для твоей системы, то ядерный модуль компилируется автоматически.

В Linux принято делать пакеты для каждого дистрибутва.

Я собственно думал что автора это устроит - остальные способы слишком опасны и трудоемки, если возможны вообще

Понимаю что тема мёртвая, но напишу-таки 'правильный ответ' для гуглящих (сам только что искал)

Вообще проблема возникла такая же, но с wxWidgets, как запаковать .so-шки, чтобы пускалось на другом дистрибутиве (в моём случае и архитектура разная: надо на debian amd64 запустить прогу с убунту x86).

Нашёл в переписке http://www.mail-archive.com/linux-development-apps@senator-bedfellow.mit.edu/msg01043.html письмо про "Subject: Re: Running an app with a different libc so than the system default?"

Суть в том, что в бинарнике жёстко зашита ссылка на /lib/ld-linux.so.2, поэтому нельзя пользоваться LD_PRELOAD/LD_LIBRARY_PATH.  Итак, берём
1) .so-шки выданные ldd my-app, в том числе libc и libstdc++
2) ld-linux.so.2

, исполняемый файл пусть будет my-app и лежит в директории app, либы из 1, 2 кладём в app/libs

запускаем так:

Тема не мертвая, а до сих пор актуальная. до этого момента  не придумал ничего лучше, чем установка в virtualbox каждого дистрибутива и сборкой под него. С ld-linux.so.2 надо будет поробовать. В любом случае спасибо.

сборка под конкретный дистр есть linux-way.... именно такой поуть обеспечивает целостность и стабильность системы в целом... и не надо тащить с привычки с винды в линукс... он от этого лучше не станет...

Это только модуль ядра, где с бинарной совместимостью действительно не очень хорошо. Юзерспейсная часть там вроде одна на все дистрибутивы.

лично я для себя выбрал такой вариант: для каждой системы (а у меня их 2 Ubuntu и CentOS) - собираю отдельно....не совсем идеально - зато практично и самое главное РАБОТАЕТ!!!