Инструменты пользователя

Инструменты сайта



// MinGW и локали

Если коротко, то всё, что связано с std::locale в MinGW не работает. Точка.

Зато вполне себе работает функционал из Си:

std::locale::global(std::locale("")); // не установит текущую локаль
setlocale(LC_ALL, ""); // установит текущую локаль, у меня это Russian_Russia.Cp1251

// MinGW32: как избавиться от зависимостей в виде libgcc_*.dll и libstdc++-*.dll?

Почти всегда программа (особенно маленькие и без инсталлятора) для win распространяется в виде законченного бандла со всеми DLL и прочим потребством. Проблема, что программа, скомпилированная примерно так:

i486-mingw32-g++ -o foo.exe foo.cpp

как минимум требует двух DLL: libgcc_*.dll и libstdc++-*.dll, что бы избавится от них можно использовать опции -static-libgcc и -static-libstdc++:

i486-mingw32-g++ -static-libgcc -static-libstdc++ -o foo.exe foo.cpp

// Библиотеки для MinGW

Некоторые библиотеки находятся в AUR, некоторые собираются сами, но есть ещё такой чудный проект как Windows KDE: http://windows.kde.org/ в рамках которого, для компиляции KDE уже отстроено много библиотек.

Найти их можно:

Ну и поиграться с версиями, начиная отсюда: http://www.winkde.org/pub/kde/ports/win32/

Что самое чудное, есть версии не только для mingw, но и для VC10, а так же версии библиотек с отладочной информацией.

UPD

Для зависимостей между модулями будет полезно: http://www.winkde.org/pub/kde/ports/win32/repository-4.8/config/config.txt

И все файлы одним списком без разделение ня kde & win32libs: http://winkde.org/pub/kde/ports/win32/releases/stable/4.8.0/

// Как узнать каким компилятором мы компилируемся?

Не всё делается одинаково во всех компиляторах, не на всех платформах, приходится временами городить хитрые конструкции из #if/#elif/#endif. Случайно наткнулся на шпаргалку, в которой описано, какие директивы препроцессора предопределяют конкретные компиляторы: http://sourceforge.net/p/predef/wiki/Compilers/

С того же ресурса:

А так же определение порядка байтов: http://sourceforge.net/p/predef/wiki/Endianness/

Другие ссылки на эту тематику:

// Набор для кросс-компиляции для Linux на ARM

Потребовалось сделать окружение для отстройки приложений для системы Linux, запущенной на платформе с процессором ARM.

Внутри есть eglibc, поэтому решено было попробовать сделать окружение с этой библиотекой Си, а не повсеместно используемой newlib.

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

Особо поразило мозг решение проблемы «кто первый: курица или яйцо?»

В результате получился набор правил для сборки окружение под ArchLinux (пакеты идут в порядке сборки):

Ну и несколько библиотек сразу в придачу:

// Boost, CMake, кросскомпиляция

  • Q: Boost.Asio - что нужно указать в cmake среди компонентов при поиске библиотеки boost?
    A: только библиотеку system:
    find_package(Boost REQUIRED COMPONENTS system)
  • Q: Boost.Thread и кроскомпиляция - что делать, если получаем ошибку вида: undefined reference to `boost::tss_cleanup_implemented()'?
    A: для начала чуток обратно: в случае Linux, в качестве компонента при поиске библиотеки нужно указывать thread, а в случае windows (и кроскомпиляции): thread_win32, т.е. необходимо писать что-то вроде такого кода:
    set(BOOST_COMPONENTS
        program_options
        system
    )
    # Boost thread library is different on Win/Linux
    if(WIN32)
      set(BOOST_COMPONENTS ${BOOST_COMPONENTS} thread_win32)
    else()
      set(BOOST_COMPONENTS ${BOOST_COMPONENTS} thread)
    endif()
     
    ...
     
    find_package(Boost COMPONENTS ${BOOST_COMPONENTS} REQUIRED)

    Подсказку увидел тут: http://lists.gnu.org/archive/html/mingw-cross-env-list/2010-11/msg00063.html. Так же следует добавить следующее (при статической линковке):

    add_definitions(-DBOOST_THREAD_USE_LIB=1)

    . Далее, собственно, относительно самого вопроса, предлагают в случае появления такой ошибки при компиляции, поместить в любой свой исходник следующее:

    namespace boost {
     void tss_cleanup_implemented() { }
    }

    чистой воды хак :) Дополнительно написано тут: http://solarcore.blogspot.com/2010/10/boost-c-threads-mingw-mac-os-x.html

// MinGW: кросс-отладка win32 приложений в Linux

По сути парочка дополнений для этой статьи: http://mingw-cross.sourceforge.net/cross_debug.html

Задача: есть win32 приложение, собранное путём кросс-компиляции при помощи cmake и mingw32, нужно запустить его в отладчике и поймать на чём оно падает.

Необходимый инстументарий:

  1. установленный mingw32
  2. wine (winconsole)
  3. бинарная версия gdb для windows, брать тут:
    http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/
  4. версия gdb, собранная для Linux, знающая как подгружать win32 приложения, собранные mingw. Тут нужно искать сборку для вашего дистрибутива, для пользователей ArchLinux я сделал PKGBUILD и поместил его в AUR:
    https://aur.archlinux.org/packages.php?ID=54802
    продвинутые пользователи могут подглядывать в мои правила сборки и собирать самостоятельно :)

Бинарную версию нужно будет распаковать, например в ~/bin/mingw32-gdb-win32/. В директорию ~/bin/mingw32-gdb-win32/bin/ при этом следует сделать следующие симлинки:

cd ~/bin/mingw32-gdb-win32/bin/
ln -s /usr/i486-mingw32/bin/libexpat-1.dll .
ln -s /usr/i486-mingw32/bin/libiconv-2.dll .
ln -s /usr/i486-mingw32/bin/libintl-8.dll .

Всё. Впринципе всё готово для отладки.

  1. Запускаем сервер:
    wineconsole cmd /K ~/bin/mingw32-gdb-win32/bin/gdbserver.exe localhost:6000 test-app.exe [аргументы для программы с которыми она должна запускаться]
  2. Запускаем клиент gdb:
    i486-mingw32-gdb test-app.exe
  3. В запущенной версии gdb выполняем следующую команду:
    (gdb) target remote localhost:6000

Ну и по сути всё, дальше делаем всё как при обычной отладке при помощи gdb, устанавливаем точки останова, смотрим данные, делаем бектрейсы и т.д. Единственная разница, что для запуска приложения нужно использовать не команду run, а команду continue, но собственно если забудете или перепутаете - отладчик вам подскажет.

Если программа что-то выбрасывает на консоль, вы увидете это в окне wineconsole.

Если захочется графической отладки, смотреть в сторону ddd и ссылку, что я давал в начале поста.

// winsock2: неблокирующийся сокет

    unsigned long arg = 1;
    ioctlsocket(sockfd, FIONBIO, &arg);

в Linux:

    int arg = fcntl(sockfd, F_GETFL, NULL);
    arg |= O_NONBLOCK;
    fcntl(sockfd, F_SETFL, arg);

или универсальная функция:

void setSockNonblock(int sockfd)
{
#ifdef WIN32
    unsigned long arg = 1;
    ioctlsocket(sockfd, FIONBIO, &arg);
#else
    int arg = fcntl(sockfd, F_GETFL, NULL);
    arg |= O_NONBLOCK;
    fcntl(sockfd, F_SETFL, arg);
#endif
}

// inet_aton для windows

Если коротко: функиця заполняет структуру типа in_addr, преобразуя сведения о хосте из строкового представления.

У winsock2 нет такой функции. Есть более продвинутый аналог inet_pton, в POSIX он тоже есть, да вот только mingw про неё в windows не знает. Пичалька.

Поэтому делаем примерно следующее:

#ifdef WIN32
static int inet_aton(const char *cp, struct in_addr *inp)
{
    if (cp == 0 || inp == 0)
    {
        return -1;
    }
 
    unsigned long addr = inet_addr(cp);
    if (addr == INADDR_NONE || addr == INADDR_ANY)
    {
        return -1;
    }
 
    inp->s_addr = addr;
}
#endif

не верх совершенства и корректности, но для моих целей работало.

// Image Ruler 0.98.1

Выпустил версию 0.98.1 программы Image Ruler для измерения на растровых изображениях.

Изменений минимум:

  • Добавлен вывод суммирующей длинны при измерении ломанной линией (столкнулся с расчётом маршрута по карте)
  • В win32 сборку добавлены плагины графических форматов: теперь из коробки открываются jpeg/gif и иже с ними, иначе работал только png.

// Crowns 0.6.0

Выпустил версию 0.6.0 программы Crowns.

Из основных изменений:

  • Добавлена возможность задавать ограничение на отображение деревьев по возрасту (кстати это поле, как я понял, в основном используется не для возраста, а для задания года «рождения» дерева)
  • Исправлен диалог редактирования данных: в нем невозможно было задать возраст дерева

// Qt4 on Mac OS X

Делал тут небольшую работку, писал программку, которая позволяла таскать линии по холсту и формировать по его данным потом xml файл в заданном формате, который потом превращался в уровень для игры. Заказчик просил ObjectivC и целевая платформа Mac OS X, на мой вопрос о критичности ObjectvC ответил - не суть, предложил написать на Qt4, тем самым покроем, одним махом, три платформы: Linux/Windows/Mac, но будет нуанс - я только примерно знаю как собирать под Mac, в общем, подумав - согласились.

Работу, естественно, я делал под Linux, проверил сборку для Windows (опять таки - кросскомпиляция). Показал результаты (сборку под Win32 и скапченый видеоролик работы в Linux), заказчику понравилось, дальше пошла очередь запуска на Mac OS X…

Первым делом был скачан Qt SDK 2010.05 - бронебойно, но зато всё сразу есть. Собрать получилось без проблем (были ворнинги у линковщика на лишние пути, указанные через атрибут -L, которые реально не существуют, но тут камень в огород создателям SDK). А вот дальше встал вопрос - а как запускать приложение на машинах где нет Qt4? Под windows/linux, в случае распространения бинарников, можно просто положить необходимые dll/so рядом и исполняемым файлов, но в Mac OS X они распространяются в виде бандла (директория с определённой структурой и суффиксом .app). Так вот, что бы собрать всё нужные библиотеки в бандл, разработчики Qt сделали утилиту macdeployqt, которую, после сборки, достаточно натравить на полученное приложение так:

macdeployqt helloworld.app

Тут человек с ником Ayoy, тоже озадачивался подобными вопросами, и рассмотрел более подробно. Так же, он столкнулся с тем, что если используются библиотеки/фреймворки которые используют Qt, после обработки macdeployqt они будут продолжать ссылаться на системные, а не те, что в бандле. Что бы это исправить он написал скрипт на перл, которые позволяет это исправлять: http://gist.github.com/109674

Чуть позже поставлю в виртуалку Mac OS X, посмотрю, может на будущее буду сам делать бандлы, а ещё заинтересовала кросс-компиляция для макоси :)

Да, в Qt Assistant страница посвященная Mac: qthelp://com.trolltech.qt.470/qdoc/deployment-mac.html версию естественно ставим свою.

// Image Ruler 0.98

Image Ruler - небольшой приложение для измерений на сканированных изображениях, например картах.

По сути анонс, хотя версии были уже выложены.

Оформил страницу проекта и выложил в для скачивания версию 0.98, по сравнению с 0.0.3 изменения:

  • исправлена ошибка с расчетом DPI и получением его из изображения (невозможно было активировать)
  • косметика интерфейса, приведен к финальному виду.

К версии 1.00 думаю будет сделано следующее:

  • краткое руководство
  • измерение в единицах отличных от миллиметров
  • оптимизация получения мета-информации из изображения
  • перевод на CMake и добавление правил для установки (make install)
  • иконку :-) кстати, кто предложит, должна отображать суть - измерения.

// Cmake, Qt4 и кросс-компиляция

Есть у меня проектик, он как тестовый полигон, хоть код и достаточно в большом количестве поддается только одной характеристике: исторически сложилось. Но на нем первом я опробовал кросс-компиляцию для Windows из Linux. Теперь его же перевел в обучающих целях на Cmake. Однако, все новое не должно отменять старых достижений, как следствие встал вопрос - а как теперь делать сборку для Windows?

С учетом того, что система сама по себе пока малознакома, решил понапрягать гугл (точнее: http://google.com/linux)

Почти сразу нашел две статьи мини-цикла:

Сделав по этому методу, немного помучавшись, получил все-таки рабочее окружение для отстройки и собрал в проект. Но не давало покоя много ручной суетливой работы, и, практически, полный отказ от уже реализованных методов поиска Qt библиотек в Cmake.

Именно по вышеуказанной причине я решил продолжить изыскания. Поиском по готовым модулям Cmake нашел упоминание некой директивы CMAKE_TOOLCHAIN_FILE, которая, по внутреннему ощущению, должна была мне помочь.

Дальнейший поиск привел меня на вики самого Cmake: How to use MinGW to cross compile software for Windows, где было сказано про тот самый toolchain file. С минимальными изменениями поместил его в каталог cmake в корне дерева проекта.

Ниже приведу листинг этого файла, назвал его win32-x-mingw32.cmake, в адоптации для ArchLinux:

win32-x-mingw32.cmake
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)
 
# which compilers to use for C and C++
SET(CMAKE_C_COMPILER i486-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i486-mingw32-g++)
SET(CMAKE_RC_COMPILER i486-mingw32-windres)
 
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH  /usr/i486-mingw32)
 
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search 
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
 
# next options is needed by some cases
#set(CMAKE_EXE_LINKER_FLAGS
#    ${CMAKE_EXE_LINKER_FLAGS}
#    -Wl,-subsystem,windows
#    -Wl,-enable-auto-import
#    -Wl,-enable-runtime-pseudo-reloc)
 
# Uncomment this if you have problem: unrecognized option '-rdynamic'
#set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS)
 
set(MINGW32 1)

Это, конечно, не все, остались последние штрихи.

Использование данного тулчайна приведет к установке переменной CMAKE_CROSSCOMPILING, на основании этого, перед вызовом

find_package(Qt4 REQUIRED)

или аналогичного, достаточно вставить (в случае ArchLinux и пакета mingw32-qt из AUR или моей репы mingw32) следующий код:

if(CMAKE_CROSSCOMPILING)
  set(QT_HEADERS_DIR "/usr/i486-mingw32/include")
  set(QT_LIBRARY_DIR "/usr/i486-mingw32/lib")
endif()

После этого сборка осуществляется примерно так:

mkdir win32-build
cd win32-build
cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/win32-x-mingw32.cmake ..
make

Все! :)

PS проверено на Cmake 2.8.1 и Qt 4.6.2

Updated: обновлён файл тулчейна

// Qt4 и кросскомпиляция для win32

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

Для начала ставим пакеты (верно для ArchLinux, для других названия будут или аналогичными, или похожими):

pacman -S mingw32-binutils mingw32-gcc mingw32-runtime mingw32-w32api qt wine

Далее, мы должны взять Windows-версию библиотеки Qt4. Берем отсюда (текущая версия 4.6, хотя лучше взять ту, которая у вас в дистрибутиве, в момент написания, это: 4.5.3, кроме того, берем ту, что дял MinGW и, мы же православные, LGPL):
http://qt.nokia.com/downloads/windows-cpp (получим самую последнюю версию)

или отсюда:
http://get.qt.nokia.com/qt/source/

Я беру 4.5.3:

wget -c http://get.qt.nokia.com/qt/source/qt-win-opensource-4.5.3-mingw.exe

После скачивания, нам поможет wine, дабы установить библиотеку2). Если у вас возникают какие ошибки и wine отваливается, попытайтесь удалить каталог ~/.wine и запустить процесс заново.

Предварительно делаем такой финт ушами:

ln -s /usr/i486-mingw32 ~/.wine/drive_c/MinGW

Пусть потом установщик думает, что у нас реальный MinGW стоит, в частности - библиотека mingwm10.dll, которую вы должны предоставить в целевой используемой системе, как и необходимые dll от Qt.

Итак:

wine qt-win-opensource-4.5.3-mingw.exe

В ходе установки локации выбирайте умолчательный - не нужно мнить себя умнее паровоза и повышать энтропию. Когда будет спрошено где установлен MinGW - жмите просто Next, если ругнется, жмите Ok - нам не страшно. По окончании сего увлекательного процесса нащупать библиотеку можно в каталоге

~/.wine/drive_c/Qt/VERSION

где VERSION это версия, в нашем случае - 4.5.3

Далее, для своего удобства, хотя это может и быть идеологически неверным, я делаю следующие пассы от root:

(1) mkdir /opt/qt4-win32
(2) cp -a /home/USER/.wine/driver_c/Qt/VERSION /opt/qt4-win32/
(3) ln -s /opt/qt4-win32/VERSION /opt/qt4-cross

где (1) - создаие каталога в общедоступной системной директории, (2) - копирование нашей установленной версии Qt4 в этот самый общедоступный каталог (USER - имя пользователя от которого происходила установка), (3) - делаем симлинк на нашу рабочую версию, этот симлинк я буду использовать в описании spec-файла для qmake.

Следующий шаг, создание спека для Qmake (любителям других систем сборок - велком с дополнениями).

Хотя создание это громко сказано, в комплекте поставки есть спек:

/usr/share/qt/mkspecs/win32-g++

для работы с mingw32 в среде Windows, нам надо его только немного модифицировать, поэтому делаем копию:

cp -a /usr/share/qt/mkspecs/win32-g++ /usr/share/qt/mkspecs/win32-cross-g++

Переходим в /usr/share/qt/mkspecs/win32-cross-g++ и, можно наложить такой патч, бай ми:

diff -Nur win32-g++/qmake.conf win32-cross-g++/qmake.conf
--- win32-g++/qmake.conf	2009-10-08 09:30:49.000000000 +1100
+++ win32-cross-g++/qmake.conf	2009-04-10 13:56:14.809651570 +1100
@@ -14,7 +14,7 @@
 QMAKE_EXT_OBJ           = .o
 QMAKE_EXT_RES           = _res.o
 
-QMAKE_CC		= gcc
+QMAKE_CC		= i486-mingw32-gcc
 QMAKE_LEX		= flex
 QMAKE_LEXFLAGS		=
 QMAKE_YACC		= byacc
@@ -27,7 +27,7 @@
 QMAKE_CFLAGS_DEBUG	= -g
 QMAKE_CFLAGS_YACC	= -Wno-unused -Wno-parentheses
 
-QMAKE_CXX		= g++
+QMAKE_CXX		= i486-mingw32-g++
 QMAKE_CXXFLAGS		= $$QMAKE_CFLAGS
 QMAKE_CXXFLAGS_DEPS	= $$QMAKE_CFLAGS_DEPS
 QMAKE_CXXFLAGS_WARN_ON	= $$QMAKE_CFLAGS_WARN_ON
@@ -41,18 +41,18 @@
 QMAKE_CXXFLAGS_EXCEPTIONS_ON = -fexceptions -mthreads
 QMAKE_CXXFLAGS_EXCEPTIONS_OFF = -fno-exceptions
 
-QMAKE_INCDIR		=
-QMAKE_INCDIR_QT		= $$[QT_INSTALL_HEADERS]
-QMAKE_LIBDIR_QT		= $$[QT_INSTALL_LIBS]
+QMAKE_INCDIR		= /usr/i486-mingw32/include
+QMAKE_INCDIR_QT		= /opt/qt4-cross/include
+#QMAKE_INCDIR_QT         = /usr/include
+QMAKE_LIBDIR_QT		= /opt/qt4-cross/lib
 
 QMAKE_RUN_CC		= $(CC) -c $(CFLAGS) $(INCPATH) -o $obj $src
 QMAKE_RUN_CC_IMP	= $(CC) -c $(CFLAGS) $(INCPATH) -o $@ $<
 QMAKE_RUN_CXX		= $(CXX) -c $(CXXFLAGS) $(INCPATH) -o $obj $src
 QMAKE_RUN_CXX_IMP	= $(CXX) -c $(CXXFLAGS) $(INCPATH) -o $@ $<
 
-QMAKE_LINK		= g++
-QMAKE_LINK_C		= gcc
-QMAKE_LFLAGS		= -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc
+QMAKE_LINK		= i486-mingw32-g++
+QMAKE_LFLAGS		= -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -mwindows
 QMAKE_LFLAGS_EXCEPTIONS_ON = -mthreads -Wl
 QMAKE_LFLAGS_EXCEPTIONS_OFF =
 QMAKE_LFLAGS_RELEASE	= -Wl,-s
@@ -72,35 +72,26 @@
 QMAKE_LIBS_COMPAT       = -ladvapi32 -lshell32 -lcomdlg32 -luser32 -lgdi32 -lws2_32
 QMAKE_LIBS_QT_ENTRY     = -lmingw32 -lqtmain
 
-!isEmpty(QMAKE_SH) {
-    MINGW_IN_SHELL      = 1
-	QMAKE_DIR_SEP		= /
-	QMAKE_COPY		= cp
-	QMAKE_COPY_DIR		= xcopy /s /q /y /i
-	QMAKE_MOVE		= mv
-	QMAKE_DEL_FILE		= rm
-	QMAKE_MKDIR		= mkdir
-	QMAKE_DEL_DIR		= rmdir
-    QMAKE_CHK_DIR_EXISTS = test -d
-} else {
-	QMAKE_COPY		= copy /y
-	QMAKE_COPY_DIR		= xcopy /s /q /y /i
-	QMAKE_MOVE		= move
-	QMAKE_DEL_FILE		= del
-	QMAKE_MKDIR		= mkdir
-	QMAKE_DEL_DIR		= rmdir
-    QMAKE_CHK_DIR_EXISTS	= if not exist
-}
-
-QMAKE_MOC		= $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}moc.exe
-QMAKE_UIC		= $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}uic.exe
-QMAKE_IDC		= $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}idc.exe
+
+MINGW_IN_SHELL      = 1
+QMAKE_DIR_SEP		= /
+QMAKE_COPY		= cp
+QMAKE_COPY_DIR		= cp -a
+QMAKE_MOVE		= mv
+QMAKE_DEL_FILE		= rm -rf
+QMAKE_MKDIR		= mkdir -p
+QMAKE_DEL_DIR		= rm -rf
+QMAKE_CHK_DIR_EXISTS = test -d
+
+QMAKE_MOC		= $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}moc
+QMAKE_UIC		= $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}uic
+QMAKE_IDC		= $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}idc
 
 QMAKE_IDL		= midl
 QMAKE_LIB		= ar -ru
-QMAKE_RC		= windres
+QMAKE_RC		= i486-mingw32-windres
 QMAKE_ZIP		= zip -r -9
 
-QMAKE_STRIP		= strip
+QMAKE_STRIP		= i486-mingw32-strip
 QMAKE_STRIPFLAGS_LIB 	+= --strip-unneeded
 load(qt_config)

или на основании этого патча, внести изменения самостоятельно.

Видно, что основные отличия это:

  • указание компилятора
  • указание путей
  • указание разделителя директорий (принудительно) и системных команд, типа копирования или переименования.

На основе этого можете делать свои правки, готовый файл спека, кому нужно - вышлю.

Второй файл qplatformdefs.h в редактировании не нуждается.

После этого следует замечание: в .pro-файле среди аргументов параметра CONFIG, не должно быть debug, и ставить туда release, иначе сборка завершается ошибкой. Почему - не разбирался, кто решит проблему - отпишите.

Ну и последние акт, запускаем qmake так:

qmake -spec win32-cross-g++ file.pro
make

Вот собственно и все, если код написан правильно и корректно, то все должно собраться и слинковаться.

PS повторюсь: не забудьте в дистрибуцию добавить нужные для работы DLL в частности mingwm10.dll (его можно взять из поставки mingw32)

PPS Полезная ссылка для Арч-юзеров, вообще для кросскомпиляции: http://aur.archlinux.org/packages.php?K=mingw32, там в том числе есть пакет mingw32-qt, в первом коменте к которому PKGBUILD собирающий пакет с Qt 4.5.3 для mingw32

2)
в общем мы можем взять копию установки с какой нить Windows-машины, разницы никакой, или попытаться собрать самому из исходников