Russian Qt Forum

Здравствуйте! В линуксе не очень разбираюсь, поэтому есть вопросы. Что нужно кроме Qt и иксов для запуска Qt приложений? Пока интересуют приложения только с интерфейсом и может подключения к базам данных? Откомпилировал проект в Сюське, запустил в Мандриве, работает, но обе установлены с полным фаршем.

Натрави ldd на свою прогу и увидишь все зависимости.

А ещё лучше в gdb 'info shared'.

Это потому что обе насколько я помню используют похожую конфигурацию системных файлов. На Debian проект вряд ли пойдет. Как советовал Пантер проверь зависимости ldd имя_исполняемого_файла, там покажутся полные пути зависимостей

Спасибо большое!!! Не знал. Поковыряюсь. Последние лет 5 устанавливал все через нет из репозиториев с помощью утилит/менеджеров пакетов. И еще вопрос: если не устанавливать Qt, можно ли таскать все необходимое вместе с прогой, по аналогии с dll-ми для виндов?

Можно. Только нужно не забыть выставить LD_LIBRARY_PATH c путём к Qt-ишным либам.

В Linux принято делать пакеты с зависимостями.

Проект пойдем на любом люнуксе, если версии используемых библиотек совпадают, или совместимы между собой... Библиотеки можно положить и рядом с своим исполнимым файлом, как делают большинство прог под Windows, но перед запуском нужно будет установить значение переменной LD_LIBRARY_PATH, например так:


PWD - переменная в которой хранится имя текущей директории.

Можно не изменять значение переменной, но тогда нужно положить библиотеки в "стандарную" папку. В OpenSuse это /usr/lib/

Спасибо за советы! А какие пакеты актуальней создавать? rpm?

Основные: rpm, deb, tar.gz. Все они делаются при помощи checkinstall.

ну так речь шла о том, собрал приложение на одном дистрибутиве и запустил на другом, безо всяких LD_LIBRARY_PATH и запихиваний своих библиотек в те же папки где у начального дистрибутива :) Уж лучше просто собрать приложение на всех совместимых дистрибутивах и создать соответствующие пакеты, благо Linux бесплатен и существует такая вещь как VirtualBox

Вы, правда, думаете, что можно собрать пакеты на все случае жизни... Под все версии дистрибутивов и все возможные конфигурации... Эх...

Можно и это использовать: void QCoreApplication::addLibraryPath ( const QString & path ) [static]

Это поможет только для плагинов.

Сам-то понял, что посоветовал?

На самом деле всё упирается в версию libc, с которой были собраны бинарники пакета. Чем ниже, тем лучше для совместимости.

Угу. Особенно если проект активно развивается. Linux от Debian до ОС Попова и т.д. а еще 32 и 64 бита... Не знаю на первый взгляд выпуск очередной версии певатится не в слишком веселое занятие. Хотя и в духе линукс. Вообще, имхо, по хорошему:
собать deb 32 / 64, rpm 32 /64 (я так думаю подойдут большинству <deb|rpm>базед дистов); архив со всеми либами(подойдут тем кому не подошел первый вариант, но не умеет/не хочет компилиовать); если возможно исходники (для всех оставшихся и любителей).

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

:) я попал....
Блин как то где то нашел и записал себе на заметку "разобраться потом".
А если так:
?

Да не так :)
Загрузка зависимых библиотек делается loader-ом до вызова main().

Хм... плохо. Т.е. если нужно это "обойти" нужно делать статически скомпилированный пускач.

А чем скрипт не подходит?

Ну нет конечно, но большинство проектов именно так и делают. Конечно если зависимостей не супер много, то можно и через LIBRARY_PATH, а что делать когда их пол системы? выпускать приложение в виде особого дистрибутива что ли? не забывайте что Qt тоже имеет свои зависимости ;)

Я думал, что работает на другом дистрибутиве по причине наличия в нем всего необходимого, что в моем случае и не странно. А смысл компилить на другом дистрибе, если там чего то не хватает, то и компиляции не получится. Или я чего то не понимаю.

Спосибо! Гляну checkinstall. Наверно rpm подойдет, линукс-админ скорее всего сумеет его установить.

По большому счету подходит. Я это так "чтобы было" :) и юзеры лишние глупые вопросы не задавали.

Не совсем так. Приложение скажем скомпилировано с Qt версии 4.7, однако реально используются функции доступные в Qt 4.5. Если скомпилить проект на дистрибутиве с 4.7 а потом попытаться запустить на дистрибутиве c Qt 4.5 то ясное дело ничего не получиться. А вот если перекомпилировать проект то все будет работать. Плюс сама библиотека Qt при компиляции использует некоторые системные библиотеки дистрибутива. Даже если перетащить вместе с проектом библиотеки Qt, проект все равно вряд ли запустить, опять же из за зависимостей, но теперь уже самой Qt.

С версиями Qt все понятно, а с системными библиотеками дистрибутива не очень. У нокии два варианта sdk под никсы 32 и 64 бита, либы один вариант определенной версии.

попробуй ldd имя_qt_библиотеки (например QtCore). Получишь все зависимости с которыми была собрана сама Qt. Если нужная системная библиотека будет версии младше чем та с которой была собрана Qt, проект не запуститься

Почему? А обратная совместимость как же?

Обратная совместимость к сожалению не распространяется на libc. :(

я бы даже сказал что не только на нее ;)

Устанавливаешь openSUSE полуторалетней давности за 25 минут и там тебе чего только нет, и качели, и карусели, красота в общем. Не хватает только дурацкого, специализированного ПО, почему-то разработанного тока под виндуз. Теперь вроде понимаю почему.

не потому что сложно с зависимостями, просто пользователям Linux не так то легко что то продать ;) значит для крупных компаний особого интереса нет

Основная причина тут, не в сложности распостранения или установки, тут можно выкрутиться - сделать пакеты для популярных дистрибутивов, написать свой инсталятор или скрипт. Проблема в распостраненности самого Linux. Большинство пользуется Windows. Большинство программистов, тоже пишут под Windows. Честно говоря Windows не такая уж и плохая система. Чаще всего основная причина перехода на Linux - это поиск альтернативы, чтобы было не как у всех. Многие проекты начали развиваться за долго до того, как в Linux появились все эти красивости. К моменту, когда Compiz стал крутить свои карусели, в окошках уже десять лет чертили в AutoCAD и рисовали в Photoshop. Переносить их на Linux... А какой смысл в этом? Если пользователь может купить Photoshop за 1000$, неужели он не сможет купить Windows за 100$.

Большинство проектов под Linux распостраняются в виде исходников. Потом на основе этих исходников собирают пакеты, но делают это чаще всего создатели или пользователи конкретного дистрибутива сами. Закрытые проекты устанавливаются через "setup" (чаще всего это shell скрипт), куски зависимости которых тянутся к системных файлам компилируются во время установки. Пример - дрова от nVidia, или Virtual Box (не OSE версии).

ИМХО!!!

С коммерческими проектами все понятно.
Бывает ПО для оборудования или обязательное ПО.
Скажем, модем Jungle yota мог-бы работать и в отличных от windows системах. 
Системы работы с турникетами пропуска, так же.
Аналитическое оборудование. 
Шифрование "Сбербанка", для тех кто с ним работает.
А в гос. учреждениях огромное разнообразие ПО тока под виндуз, которое с трудом можно заставить работать на нем. Зачастую даже не учитывают, что пользователь может иметь права отличные от администратора и другие особенности ОС Windows.
Дурацкая программулька россимущества требует net framework 3.5, при этом, если винда была English sp1, русифицирована и обновлена до sp2, то работать не захочет. Систему для работы с казначейством долгое время не рекомендовалось устанавливать на Windows отличный от 2000 SP4, локальные данные там хранятся в файле access, который редко бывает меньше 200МБ.
Если вы захотите открыть орган по сертификации, придется установить ПО на LOTUS NOTES, сам LOTUS хоть и кроссплатформенный, но будет чудом если вы все установите и настроите без программиста лотус, хотя бы на ОС Windows.
Подобных примеров очень много.