Как настроить Qt для кросс-компиляции под Linux для Windows?
Я хочу скомпилировать библиотеки Qt (и в конечном итоге мое приложение) для цели Windows x86_64 с помощью хост-машины Linux x86_64. Я чувствую, что я близок, но у меня может быть фундаментальное непонимание некоторых частей этого процесса.
я начал с установки всех пакетов mingw на моей машине Fedora, а затем изменил win32-g++
qmake.conf, чтобы соответствовать своей среде. Тем не менее, я, кажется, застрял с некоторыми, казалось бы, очевидными настройками для Qt: -platform
и -xplatform
. Документации Qt говорит, что -platform
должна быть архитектура хост-машины (где вы компилируете) и -xplatform
должна быть целевая платформа,для которой вы хотите развернуть. В моем случае, я установил -platform linux-g++-64
и -xplatform linux-win32-g++
где linux-win32-g++ - это моя измененная конфигурация win32-g++.
моя проблема заключается в том, что после выполнения configure с этими параметрами я вижу, что он вызывает компилятор моей системы вместо кросс-компилятора (x86_64-w64-mingw32-gcc). Если я опущу и set -platform
для моей целевой спецификации (linux-win32-g++) он вызывает кросс-компилятор, но затем ошибки, когда он находит некоторые функции, связанные с Unix, не определены.
вот некоторые результаты моей последней попытки:http://pastebin.com/QCpKSNev.
вопросы:
при кросс-компиляции чего-то вроде Qt для Windows с хоста Linux, должен ли собственный компилятор когда-нибудь вызывается? То есть, во время процесса кросс-компиляции, мы не должны использовать только кросс-компилятор? Я не понимаю, почему сценарий настройки Qt пытается вызвать собственный компилятор моей системы, когда я указываю .
если я использую кросс-компилятор mingw, когда мне придется иметь дело с файлом спецификаций? Файлы спецификаций для GCC по-прежнему остаются для меня загадкой, поэтому мне интересно, поможет ли мне какой-то фон.
в общем, за указание кросс-компилятора в моем qmake.конф, что еще мне нужно учесть?
5 ответов:
просто использовать M cross environment (MXE). Это снимает боль из всего процесса:
сделать это:
$ git clone https://github.com/mxe/mxe.git
установить зависимостей построить
сборка Qt для Windows, ее зависимостей и инструментов кросс-сборки; это займет около часа на быстрой машине с приличным доступом в интернет ; загрузка составляет около 500 МБ:
$ cd mxe && make qt
перейти к каталог вашего приложения и добавьте инструменты кросс-сборки в путь переменные среды:
$ export PATH=<mxe root>/usr/bin:$PATH
запустите инструмент Qt Makefile generator и постройте:
$ <mxe root>/usr/i686-pc-mingw32/qt/bin/qmake && make
вы должны найти двоичный файл в./ каталог релизов:
$ wine release/foo.exe
заметки:
используйте главную ветвь репозитория MXE; похоже, он получает гораздо больше любви от группа разработчиков.
выход представляет собой 32-разрядный статический двоичный файл, который будет хорошо работать на 64-разрядных Windows.
(это обновление ответа @Tshepang, поскольку MXE эволюционировал с момента его ответа)
Сборка Qt
вместо
make qt
чтобы построить Qt, вы можете использоватьMXE_TARGETS
для управления целевой машиной и инструментальной цепью (32 - или 64-разрядной). MXE начал использовать.static
и.shared
как часть целевого имени, чтобы показать, какой тип lib вы хотите построить.# The following is the same as `make qt`, see explanation on default settings after the code block. make qt MXE_TARGETS=i686-w64-mingw32.static # MinGW-w64, 32-bit, static libs # Other targets you can use: make qt MXE_TARGETS=x86_64-w64-mingw32.static # MinGW-w64, 64-bit, static libs make qt MXE_TARGETS=i686-w64-mingw32.shared # MinGW-w64, 32-bit, shared libs # You can even specify two targets, and they are built in one run: # (And that's why it is MXE_TARGET**S**, not MXE_TARGET ;) # MinGW-w64, both 32- and 64-bit, static libs make qt MXE_TARGETS='i686-w64-mingw32.static x86_64-w64-mingw32.static'
в оригинальном ответе @Tshepang он не указал
MXE_TARGETS
, и используется значение по умолчанию. На когда он писал свой ответ, по умолчанию былi686-pc-mingw32
, сейчас этоi686-w64-mingw32.static
. Если вы явно установилиMXE_TARGETS
доi686-w64-mingw32
, минуя.static
, выводится предупреждение, так как этот синтаксис теперь устарел. Если вы попытаетесь установить цель вi686-pc-mingw32
, он покажет ошибку, поскольку MXE удалил поддержку MinGW.org (т. е. i686-pc-mingw32).под управлением
qmake
как мы изменили
MXE_TARGETS
на<mxe root>/usr/i686-pc-mingw32/qt/bin/qmake
команда больше не будет работать. Теперь, что вам нужно сделать это:<mxe root>/usr/<TARGET>/qt/bin/qmake
если вы не указать
MXE_TARGETS
сделайте так:<mxe root>/usr/i686-w64-mingw32.static/qt/bin/qmake
обновление: новое значение по умолчанию теперь
i686-w64-mingw32.static
хорошо, я думаю,что я понял это.
частично на основе https://github.com/mxe/mxe/blob/master/src/qt.mk и https://www.videolan.org/developers/vlc/contrib/src/qt4/rules.mak
похоже, что "изначально" при запуске configure (with-xtarget и т. д.), он настраивает затем запускает ваш" hosts " gcc для создания локального двоичного файла ./ bin / qmake
./configure -xplatform win32-g++ -device-option CROSS_COMPILE=$cross_prefix_here -nomake examples ...
затем вы запускаете обычный "make", и он строит его для mingw
make make install
так
да
только если вам нужно использовать что-то другое, чем msvcrt.dll файлы (по умолчанию). Хотя я никогда не использовал ничего другого, поэтому я не знаю наверняка.
https://stackoverflow.com/a/18792925/32453 перечисляет некоторые параметры настройки.
чтобы скомпилировать Qt, нужно запустить его
configure
скрипт, задающий хост-платформу с помощью-platform
(например,-platform linux-g++-64
Если вы строите на 64-битном linux с компилятором g++) и целевой платформы с-xplatform
(например,-xplatform win32-g++
если вы выполняете кросс-компиляцию в windows).Я также добавил этот флаг:
-device-option CROSS_COMPILE=/usr/bin/x86_64-w64-mingw32-
который указывает префикс используемой мной инструментальной цепочки, которая будет добавлена к "gcc" или " g++" во всех файлах Makefile, которые создают двоичные файлы для окна.наконец, вы можете получить проблемы при строительстве icd, который, по-видимому, является чем-то, что используется для добавления поддержки ActiveX в Qt. Вы можете избежать этого, передав флаг
-skip qtactiveqt
для скрипта configure. Я получил это из этого сообщения об ошибке:https://bugreports.qt.io/browse/QTBUG-38223вот вся команда настройки, которую я использовал:
cd qt_source_directory mkdir my_build cd my_build ../configure \ -release \ -opensource \ -no-compile-examples \ -platform linux-g++-64 \ -xplatform win32-g++ \ -device-option CROSS_COMPILE=/usr/bin/x86_64-w64-mingw32- \ -skip qtactiveqt \ -v
Что касается ваших вопросов:
1 - Да. Абориген компилятор будет вызван для того, чтобы построить некоторые инструменты, которые необходимы в процессе сборки. Может быть, такие вещи, как qconfig или qmake, но я не совсем уверен, какие именно инструменты.
2 - к сожалению. Я понятия не имею, какие файлы спецификаций находятся в контексте компиляторов =/ . Но, насколько я знаю, тебе не придется иметь с этим дело.
3-Вы можете указать префикс кросс-компилятора в командной строке configure вместо того, чтобы делать это в qmake.файл conf, как сказано выше. И есть также эта проблема с idc, чей обходной путь я также упомянул.
еще один способ кросс-компиляции программного обеспечения для Windows на Linux является MinGW-w64 toolchain на Archlinux. Это простой в использовании и обслуживании, а также предоставляет последние версии компилятора и библиотек. Я лично считаю, что это проще, чем MXE, и, похоже, быстрее принимает новые версии библиотек.
сначала вам понадобится машина на основе arch (достаточно виртуальной машины или контейнера docker). Это не обязательно должен быть Arch Linux, производные также будут делать. Я использовал Манджаро Линукс. Большинство пакетов mingw-w64 недоступны в официальных репозиториях Arch, но есть много в AUR. Менеджер пакетов по умолчанию для Arch (pacman) не поддерживает установку непосредственно из AUR, поэтому вам нужно будет установить и использовать оболочку Aur, такую как pacaur или yaourt. Затем установка MinGW-w64 версии Qt5 и Boost библиотек так же просто, как:
pacaur -Sy mingw-w64-qt5-base mingw-w64-boost #yaourt -Sy mingw-w64-qt5-base mingw-w64-qt5-boost #if you use yaourt
это также установит инструментальную цепочку mingw-w64 (
mingw-w64-gcc
) и другие зависимости. Кросс-компиляция проекта Qt для windows (x64) тогда так же просто, как:x86_64-w64-mingw32-qmake-qt5 make
для развертывания программы вам нужно будет скопировать соответствующие файлы dll из
/usr/x86_64-w64-mingw32/bin/
.чтобы получить 32-битную версию, вам просто нужно использовать . Проекты на основе Cmake работают так же легко с
x86_64-w64-mingw32-cmake
. Этот подход работал очень хорошо для меня, был самым простым в настройке, обслуживании и расширении. Он также хорошо сочетается со службами непрерывной интеграции. Есть докер изображения слишком доступен.например, допустим, я хочу построить QNAPI subtitle downloader GUI. Я мог бы сделать это в два этапа:
1) Запустите контейнер docker:
sudo docker run -it burningdaylight/docker-mingw-qt5 /bin/bash
2) клонировать и компилировать QNapi
git clone --recursive 'https://github.com/QNapi/qnapi.git' cd qnapi/ x86_64-w64-mingw32-qmake-qt5 make
вот именно! Во многих случаях это будет так легко. Добавление собственных библиотек в репозиторий пакетов (AUR) также является простым. Вам нужно будет написать файл PKBUILD, который является интуитивно понятным, как это может получить, смотрите mingw-w64-rapidjson, например.