[Решен] Static build
-
Опитвам се да направя static build на Qt библиотеките, като целта ми е да се улесни разпорстранението на програмата под линукс - да не е необходимо да се инсталира Qt за съответната платформа, а всичко да е "вградено" в стартиращия файл. Проблема ми идва от libmng - на всички 32 битови линукски дистрибуции си работи нормално, но когато се пусне на 64 бита, libmng е библиотеката която "липсва". Конфигурирах инсталацията по следния начин:
@
./configure -static -opensource -prefix /usr/local/qt-static -qt-zlib -qt-gif -qt-libpng -qt-libmng -qt-libjpeg -nomake demos -nomake examples
@След make, make sub-src, make install, единствената библиотека с подобно име в директория която е от директориите на Qt е следната:
/usr/lib/qt4/plugins/imageformats/libqmng.soПри компилацията не ми дава никакви грешки. При задаването на /usr/local/qt-static/bin в PATH-а и компилирането на програмата, не може да намери библиотеката (добавям QTPLUGIN .pro файла). Мога успешно да компилирам програмата само ако в .pro файла сложа "QTPLUGIN += mng". Пробвах с libmng, libqmng, qmng, libqtmng и всякакви подобни вариации - без резултат. В main.cpp добавих:
@
#include <QtPlugin>Q_IMPORT_PLUGIN(qmng)
@
и пак по същия начин пробвах с различни варианти на qmng, разбира се еднакви с тези в .pro файла, без резултат. Очевидно не може да се "построи" библиотеката, но не виждам какво не е наред, защо не се получават нещата. Някой има ли опит в построяването на такива програми? Дайте някаква насока..... -
Здравей,
мисля че няма от както да се притесняваш, че Qt няма да е инсталирана на потребителската машина. Май няма голяма Линукс дистрибуция, която да няма Qt.
Статичната библиотека също така би прецакала външния вид на приложението ти. Статичното Qt не се вързва добре с избраната от теб тема(за пример виж Скайп).
Друго, което ми хрумва е: трябва ли ти наистина mng формата? Ако програмата ти няма да го използва, няма нужда да билдваш Qt с поддръжка за него. Същото важи и за другите модули, които си подал като опция. Премахването на ненужните модули, ще намали размера на изходният код на програмата ти.
-
Да, съгласен съм напълно, просто рещих всички image формати да са включени, за всеки случай. Крайния резултат - голям стартиращ файл (15 мегабайта беше последния).
В програмата си ползвам PNG файлове - няколко кртинки за икони на бутони, фонове и подобни. Чудех се ако иконите ги прехвърля в друг формат дали ще ми изисква въобще библиотеки за картинки (примерно .ico).
Не съм съгласен за темата, можеш да видиш скрийншотовете на програмата от адреса който съм добавил в другата тема и ще видиш че на линукс и уиндоус изглежда сравнително еднакво, като аз съм доволен от визията за момента.
Проблема е че не искам да карам хората да теглят Qt допълнително (има системи които не ползват kde библиотеки, съответно не са помирисвали Qt). В интерес на истината по начина по който съм го построил, единствената зависимост е libmng, като тя е по- скоро проблем на 64 битови платформи. На 32 битовите, хората си теглят libmng и всичко е ОК. Заради това искам да е "монолитно" =/
-
Като гледам програмата ти не зарежда картинки, подадени от потребителя, така че ти си определяш какво и трябва. В какъвто и формат да ги превърнеш, ще ти трябва библиотека, която да декодира картинката. Единственият начин да се отървеш напълно е картинките ти да са като статични двумерни масиви в програмата - width x height големи.
-
Хм, не бях се замислял за този подход.... Може би това ще е по- добрия вариант за да се отърва от libmng. Да, потребителите не подават картинки по никакъв начин. Ще ме затрудни обаче правенето на тея масиви, плюс това бих искал да си остане структората както в момента - да имам ресурсен файл в който да се намират всички картинки.
Сега като се замисля, по едно време правих едни простотии с обработка на трей иконата.... вземах активната икона, драсках по нея и я слагах обратно. Оставил съм тази част от кода само за reference в бъдеще, но може би не съм изчистил инкуловете и заради това да ми иска библиотека за обработката им.... ще проверя дали не е това проблема, мерси че обсъждаш с мен проблема за да мога да го докарам до някакво задоволително решение :D
Edit: Не е там проблема.... във файла на класа който екстендва QMainWindow инклудвам QtGui, всичко останало са класовете които аз съм писал, никъде няма нищо свързано с обработката на икони, картинки и други..... Как да реша проблема на 64 битовите машини.... не мога да компилирам отделно 64 битова версия :S
-
Като гледам така май най-добре ще е да използваш XPM формата. Той ще ти намали размера на изображенията, тъй като не използва масив с елемент за всеки пиксел, а има индексиране по цветове. Това значително би намалило паметта, която ще се използва за пазене на картинката, особено ако тя е с по-малко на брой цветове и има напълно прозрачни части. За да си генерираш XPM масивите може да използваш GIMP. Той може да запазва картинка в този формат.
-
XPM-а е един char масив, вграден в кода ти, който се интерпретира от Qt. Не би трябвало да има проблем.
-
XPM-а не може да се разбере с алфа-блендинга.... разваля се цялата идея от картинките :(
Edit: В интерес на истината не изглежда зле под линукс, сега ще прекомпилирам библиотеките без imageformats и ще видя как ще се вижда на други системи.
Edit2: Няма резултат.... Проблема идва от това че ползвам QtGui в което има декларирани методи за работа с графики/картинки. Опитах се да заменя QtGui с QtCore, но ползвам qApp макроса на няколко места, примерно за достъп до клипборда, съответно няма как да "прескоча" QtGui. Ако случайно пък намеря варианти за прескачането му, не знам какво друго ще "гръмне". Май ще се откажа въобще от потребители с 64 битови платформи :(
-
Странна работа, май се оказва че въпросните 3rd party библиотеки не са се билдвали заради липсата на zlib. Ребилднах Qt библиотеките общо взето по същия начин, само изключих qt-gif (даваше ми грешка, което е странно....) и сложих zlib последна, добавих "- nomake tools" за да не ми билдва и криейтора, след това "make sub-src; make install" и това беше. Този път успях да компилирам монолитен стартиращ файл и не му трябва libmng! Струва ми се че разликите между "make" и "make sub-src" са по- големи от колкото е описано в документациите.....
Мерси за помощта въпреки всичко ;-)