Как мне скомпелировать свой проект, например, что бы он мог корректно работать на другой OS(например для Windows, если я пишу в Linux-e).
Смотрю QT assistant, но все не могу найти, об этом никакой полезной инфы... :(
Всмысле в Линуксе все нормально компилится, но как мне получить .exe файл для Windows?

Это сообщение отредактировал(а) devmstr - 2.12.2007, 19:20

теоретически, можно попробовать кросс-компиляцию. Практически - столько гемора, что легче поставить Windows на виртуальную машину и скомпилировать там.

Придерживаюсь того же мнения. Даже теоретически - возьни будет столько, что себе дороже.

Ну, не знаю, как у кого. В дженту есть пакет crossdev, с помощью него ставим mingw32 (который будет собран под нашу платформу, но, само собой, генерить будет PE-шные файлы). Есть модули для eselect для переключения между профилями для компилятора, binutils, etc. В частности собирал так qemu (почти qemu), замучивись с MSys и всей путанницей под виндой.

Кросскомпиляция возможна (в любую сторону). Насчёт гемморно или нет - вручную не собира ни мингв под линем, ни линёвый гцц. Кто его знает...

угу. ты мне буст собери под линухом для вин32. Компилятор, линкер, binutils, всё есть, что душа пожелает. Проблема в том, что мэйкфайлы не понимают, как собирать виндовые бинарники под линухом. Либо .so мне пихают, либо пытаются делать copy bla\foo\bar. > NUL в самом начале компиляции.

Ну его... себе дороже.

Любитель, дело в том, что Qt немного более сложная система, чем MinGW(с ней и под виндой то бывают недопонимания в вопросах сборки - что уж говорить про кросскомпиляцию).
Точнее, господа из TT сделали её таковой, хотя, можно было сделать всё намного проще(мне так кажется).

Грусно это всё :((

Врать не буду - не пробовал. Завтра приеду в Воронеж, вечером (за своим компом) попробую. 


Опчть-таки сам не пробовал, ибо нафиг не надо было. Но уж конкретно по кросскомпайлу куте столько туториалов... Специально попробую  Скажем такой вриант: сама Qt + все стандартные демки без ActiveQt (вот за это не берусь) + возможно, без директ-иксовского рендеринга, собираются под моим дженту. В течение следующей недели отпишусь о результатах 

Ок?

Давай. Будем только благодарны за полученный опыт .

договорились. Я буду искренне рад, если ты сумеешь буст кросс-собрать.
Про QT тоже весьма интересно 



Это сообщение отредактировал(а) JackYF - 2.12.2007, 21:07

Если получится, будет супер!!

Ну, важно ещё, чтобы не просто получилось, а получилось при разумном количестве затрат 

Итак - добрался, наконец, до дома, отпишусь о текущих результатах 

Сразу решил ориентироваться, само собой, на произвольный дистр (никаких emerge crossdev!). Впрочем, по крайней мере насчёт самого МинГВ, всё оказалось банально до ужаса - на sf.net/projects/mingw есть готовый скрипт, задающий достаточно очевидные вопросы - с помощью него собрать кросскомпилятор не составит труда. То, что в итоге получилось, располагается (по дефолту) в ~/mingw. Соответственно ~/mingw/bin/* - исполняемые бинарники + рантаймовая длл-ка. Правда имеют они вид, что-то вроде (у меня) i686-mingw32-g++. Всё-таки так как все ожидабт видеть просто g++, gcc, ld, etc. - сделаем для простоты соответствующие симлинки (можно, конечно, понаставить более интелектуальных детектов - но оно нам надо?). Я делал  банально так:



Буст
Итак, первым пунктом у нас был буст  Нативная версия у меня, конечо, уже стояла (по сути, нужен лишь bjam). Распаковываем куды-нибудь сорсы. Теперь чуток поиздеваемся на jam-скриптами. Расположены они в tools/build/v1. Операционка вшивается в bjam при его сборке - то есть мой bjam уже знал, что он работает на лине. Вначале попробовал обмануть его тупо-нагло: добавил в самое начало allyourbase.jam:



Этот вариант так просто не заработал. Дело даже не в том, что у меня cp вместо (x)copy и rm вместо del - это объяснить несложно. По непонятной причине вместо вызова компилятора я получал лишь вывод в консоль команды - и всё. Затем вызывался objcopy (чтой-то там с секциями творил - фиг его зачем): от него также выводилась строка вызова, но плюс он вызывался физически (и жаловался на отсутствие входного объектника). При ручном повторении команд всё срабатывало нормально - но это не выход.

Поэтому я оставил в покое справедливое мнение бэджама о мое ОСи. Вместо этого добавил в начало allyourbase.jam следующее (если посмотерть ниже этого же файла, то понятно - почему именно это  ):



Впрочем, были ещё несколько изменений - аттачу дифф оргинальной tools/buildv1 и пропатченной.

Ещё не особо хотелось собирть питон под винду (архив с сорсами-то по идее один - но всё равно не охота). А так как, он (bjam) успешно продетектил мой питончик и начал хавать инклюды из /usr/include, а затем ругаться на всякий бред (вообщем-то понятно - какие-то конфиг.х, наверно, у питона есть...) - просто пробилдил без буст.питона:


Правда, в процессе билдинга получил кучу надписей о "FileClone action failed" - но это касалось попытки создать симлинки (учитывая LN = cp - просто копии) вида <libname_bla_bla_bla>.dll.1.3.31 -> <libname_bla_bla_bla>.dll. Откуда это исходило искать не стал - ибо билдинг, как таковой, от этого не обрывался, а бесполезный варнинг меня не слишком беспокоил. 

Вообщем, в stage получили всё, что надо, простые тесты собираются, работают из-под вайна (при копировании соответствующих длл-ок - если линкуем динамически). Вроде всё нормально.

Куте
С куте пока несколько похуже. :(

Проблема №1 - не обнаружил на компе сорсов от вин-версии.   От никсовой они несколько отличаются (на вскидку - в никсовую совсем не включена папочка винмейн). Вообщем, первые попытки собрать из никсовой версии что-то обломились быстро 

Проблема №2 - виндовую версию достал только в пятницу. Что получилось сделать за вечер:

1. Вроде-бы нормальную генерацию мейкфайлов для разных простых тестов.

2. Компиляцию всей куте. И получению статических либ куте вида lib<lib_name>.a. Конечно, пытался собрать shared    

Вообщем, если есть готовая нормально собранная куте - проблем скорее всего быть не должно. Но (!) - я не проверял:

1. Ищем, где у нас находятся mkspecs (в критическом случае пишем тривиальную программу, юзающую QLibraryInfo) - у меня сие /usr/share/qt4/mkspecs.

2. Создаём там какую-нибудь папочку - скажем, cross-mingw32.

3. В неё копируем всё из win32-g++ (два файла).

3. Из них берём qmake.conf и ищем строку проверки на MSys (MINGW_IN_SHELL, по-моему). Убираем всё проверку, и всю ветвь else (для чистого МинГВ) - оставлям мсисовский (блин, звучит!) ввариант (cp, rm, etc.).

4. В том же файле прописываем полные пути для g++, gcc, ar, etc. А также инклюд-директорию mingw, lib и include директории Qt. Для билдинга Qt ещё (к слову  )) понадобится QT_SOURCE_TREE - путь к самой распакованной куте.

5. В начало того же файла всовываем строки из <наша_МинГВшная_куте>/mkspecs/qconfig.pri.

6. Всесто qmake запускаем qmake -spec cross-mingw32 (затем обычный make).

Для простых проджект-файлов с lib-темплейтом и строкой dll в конфиге (dll в кумейовскиз проджектах юзается для любых  шаред-либ - на любой платформе) - проверял, получая нормальный мейкфайл (с длл-кой в качестве тарджета  ). В самой куте почему-то сие не так. Там правда, всё посложнее: куча инклюдов всяких *.pri - в итоге dll добавляется в конфиг уже из одного из pri-шек в недрах mkspecs/features. Вообщем - не было уже времени разбираться :(

Ну, пока вот-так вот... 

Это сообщение отредактировал(а) Любитель - 9.12.2007, 03:58

Любитель, за буст я снимаю шляпу. И попрошу всё-таки приаттачить дифф к сообщению или на мыло выслать, я-то не от праздного интереса хотел буст кросс-компилировать 

Сорри, пока писал - забыл   

Присоединённый файл ( Кол-во скачиваний: 18 )
 boost.diff 2,42 Kb