Как настроить 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.conf, что еще мне нужно рассмотреть?
5 ответов
просто использовать M cross environment (MXE). Это избавляет от боли весь процесс:
Build Qt для Windows, его зависимости и инструменты кросс-сборки; это займет около часа на быстрой машине с приличным доступом в интернет ; загрузка составляет около 500 МБ:
перейти к каталог вашего приложения и добавьте инструменты кросс-сборки в путь переменные среды:
запустите инструмент генератора Qt Makefile, затем постройте:
вы должны найти двоичный файл в./ каталог выпуска:
заметки:
используйте главную ветвь репозитория MXE; кажется, что он получает гораздо больше любви от группа разработчиков.
выход 32-разрядный статический двоичный файл, который будет хорошо работать на 64-разрядных Windows.
(это обновление ответа @Tshepang, поскольку MXE эволюционировал с момента его ответа)
Сборка Qt
вместо make qt чтобы построить Qt, вы можете использовать MXE_TARGETS для управления целевой машиной и цепочкой инструментов (32 — или 64-бит). MXE начал использовать .static и .shared как часть целевого имени, чтобы показать, какой тип lib вы хотите построить.
в первоначальном ответе @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 , the /usr/i686-pc-mingw32/qt/bin/qmake команда больше не будет работать. Теперь, что вам нужно сделать есть:
если вы не указать MXE_TARGETS сделайте так:
обновление: новое значение по умолчанию теперь i686-w64-mingw32.static
хорошо, я думаю,что я понял это.
Кажется, что «изначально» при запуске configure (with-xtarget и т. д.), он настраивает затем запускает ваш gcc «hosts» для создания локального двоичного файла ./ bin / qmake
затем вы запускаете нормальный «make», и он строит его для компилятор MinGW
только если вам нужно использовать что-то другое, кроме msvcrt.dll файлы (по умолчанию). Хотя я никогда не использовал ничего другого, поэтому я не знаю наверняка.
для компиляции 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
вот вся команда configure, которую я использовал:
Что касается вопросов yout:
1 — Да. Абориген компилятор будет вызван для создания некоторых инструментов, необходимых в процессе сборки. Может быть, такие вещи, как qconfig или qmake, но я не совсем уверен, какие именно инструменты.
2 — к сожалению. Я понятия не имею, какие файлы спецификаций находятся в контексте компиляторов =/ . Но, насколько я знаю, тебе не придется иметь с этим дело.
3 — Вы можете указать префикс кросс-компилятора в командной строке configure вместо того, чтобы делать это в qmake.файл conf, как сказано выше. И существует также эта проблема с idc, чей обходной путь я также упомянул.
другой способ кросс-компиляции программного обеспечения для Windows на Linux-это цепочка инструментов mingw-w64 на Archlinux. Он прост в использовании и обслуживании и предоставляет последние версии компилятора и множество библиотек. Я лично считаю, что это проще, чем MXE, и, похоже, быстрее принимает новые версии библиотек.
сначала вам понадобится машина на основе arch (достаточно виртуальной машины или контейнера docker). Это не обязательно должен быть Arch Linux, производные также будут делать. Я Manjaro Линукс. Большинство пакетов mingw-w64 недоступны в официальных репозиториях Arch, но есть много в AUR. Менеджер пакетов по умолчанию для Arch (pacman) не поддерживает установку непосредственно из AUR, поэтому вам нужно будет установить и использовать оболочку Aur, такую как pacaur или yaourt. Затем установка MinGW-w64 версии библиотек Qt5 и Boost так же проста, как:
это также установит цепочку инструментов mingw-w64 ( mingw-w64-gcc ) и другие зависимости. Кросс-компиляция проекта Qt для windows (x64) тогда так же проста, как:
чтобы развернуть программу, вам нужно будет скопировать соответствующие библиотеки DLL из /usr/x86_64-w64-mingw32/bin/ .
чтобы получить 32-битную версию, вам просто нужно использовать . Проекты на основе Cmake работают так же легко с x86_64-w64-mingw32-cmake . Этот подход работал очень хорошо для меня, был самым простым в настройке, обслуживании и расширении. Это также хорошо сочетается со службами непрерывной интеграции. Есть докер изображения слишком доступен.
например, предположим, я хочу построить QNAPI subtitle downloader GUI. Я мог бы сделать это в два шага:—9—>
1) Запустите контейнер docker:
2) клонировать и компилировать QNapi
вот именно! Во многих случаях это будет так легко. Добавление собственных библиотек в репозиторий пакетов (AUR) также просто. Вам нужно будет напишите файл PKBUILD, который является интуитивно понятным, как он может получить, см.mingw-w64-rapidjson, например.
QtCreator: Qt кросс-компиляция из linux 64 в linux 32, win32, win64 и Mac OS X; upx, usb, dmg, etc
Библиотека Qt позволяет делать действительно кроссплатформенные приложения. Единожды написанный код можно откомпилировать под многие операционные системы. Но проблема именно в слове «компилировать», т.к. подразумевается, что необходимо перезагрузиться под целевую систему, иметь в ней настроенную среду разработки, установленный и настроенный зоопарк библиотек. Спасает кросс-компиляция — компиляция, производящая исполняемый код для платформы, отличной от той, на которой исполняется.
Кросс-компиляция для Windows 64
Обычно одной из наиболее востребованных проблем является сборка Windows-версии своего приложения, изначально разрабатывающегося под Linux. Пример решения этой проблемы можно увидеть тут или на русском. Необходимо создать mkspecs-конфигурацию, положить файлы Qt в соответствующие директории и всё. Компилировать Qt в таком случае не обязательно, можно скачать бинарники с официального сайта.
У такого подхода есть несколько минусов: 1) QtCreator об установленной таким образом библиотеке ничего не знает; 2) Официальной сборки Qt для Windows x64 не существует. И если с первой проблемой ещё как-то можно бороться, то против второй поможет только компиляция…
Перед кросс-компиляцией не забудьте поставить непосредственно сам кросс-компилятор (ищется в пакетом менеджере по названию «mingw»). И скачать исходники qt-everywhere с официального сайта. В директории mkspecs распакованного архива копируем папку win32-g++ в win64-x-g++ и корректируем содержимое файла qmake.conf. У меня получилось следующее:
По сути в файле спецификации были заменены только пути.
Я выполнял configure со следующими параметрами:
./configure -xplatform win64-x-g++ CROSS_COMPILE=x86_64-w64-mingw32- -prefix /usr/local/qt4win64 -no-webkit -no-phonon -no-phonon-backend -no-script -no-scripttools -no-multimedia -no-qt3support -fast -nomake demos -nomake examples -nomake tools -device-option -little-endian -qt-zlib -qt-libpng -qt-libjpeg -openssl-linked -no-fontconfig -no-3dnow -no-ssse3 -continue
Здесь собираю минимальную версию Qt без webkit, phonon, multimedia и т.п. Полный список опций можно посмотреть по команде ./configure —help
Соответственно, для такой сборки должен быть установлен пакет g++-mingw-w64-x86-64, содержащий в себе x86_64-w64-mingw32-g++ (в убунту пакет надо ставить отдельно).
Далее make && sudo make install. На первом этапе компиляции используется родной системный компилятор, он собирает необходимые утилиты для linux, которые будут использоваться для сборки уже windows-бинарников.
После установки у меня в /usr/local/qt4win64/bin лежат PE32+ DLL и несколько ELF 64-bit LSB executable, в том числе: qmake, uic, moc, rcc. Вот они то и пригодятся для QtCreator!
После установки не удаляйте распакованную директорию — она используется.
Кросс-компиляция для Windows 32
Аналогична компиляции для Win64. За исключением того, что есть официальная сборка, и саму библиотеку компилировать не нужно! Достаточно собрать qmake, uic, moc, rcc.
Кросс-компиляция для Mac OS X
Кросс-компиляция для мака тоже очень похожа, за исключением того, что надо будет собрать и компилятор. Я собирал по этой инструкции. Это отняло полный день времени и кучу нервов. В процессе будет нужна рабочая Mac OS X (как минимум на виртуальной машине) с установленным XCode, чтобы взять оттуда необходимые файлы. При компилировании своих Qt-приложений запущенная Mac OS X не нужна.
Помните, в Mac OS X для линковки с библиотекой .a-файлы не нужны.
Настройка QtCreator
Сначала нужно добавить в список все установленные компиляторы. Инструменты — Параметры — Сборка и запуск — Инструментарии: 
QtCreator обычно нормально определяет ABI, но лучше перепроверить. Так же можно заметить, что системный x64 GCC в linux умеет генерировать и 32-битные приложения. Однако это не отменяет того, что также необходимы 32-битные версии библиотек.
После компиляторов можно добавить профили Qt: 
Вот при добавлении профиля и пригодятся собранные ранее qmake, uic, moc, rcc, ведь нужно выбрать директорию с qmake. Жёлтый значок с восклицательным знаком слева от профиля означает warning, но QtCreator может использовать такой профиль Qt. А вот если значок красный, то профиль нерабочий. Такое может случиться при неправильной структуре каталогов. Или если удалить директорию, в которой компилировали Qt.
Следующие настройки нужно делать в каждом создаваемом проекте.
Для добавления конкретного профиля Qt надо при активном проекте зайти на вкладку «Проекты» (Ctrl+5): 
По умолчанию в списке «Изменить конфигурацию сборки» есть только системный профиль Qt. Зато в списке кнопки «Добавить» есть все профили Qt, добавленные в параметры сборки.
В основных настройках сборки необходимо проверить пару библиотека-компилятор. Чтоб и то и другое было от одной и той же операционной системы.
Этапы сборки «qmake» и «Сборка» QtCreator ставит по умолчанию. А вот особые этапы «upx» и «dmgbuild» я добавил вручную для своего проекта. Этап «upx» выполняется каждый раз при нажатии на кнопку «Собрать проект». Однако если исполняемый файл не был изменён, то upx вернёт ошибку, что файл им уже обработан. В случае ошибки следующий этап не вызывается, т.е. dmg-файл обновится только если upx отработал успешно.
Для работы этапа upx он должен быть установлен в системе. Однако даже работая в linux-окружении и поставленный из пакетного менеджера upx умеет ужимать приложения: linux32/64, win32, macos32/64. Далеко не для всех проектов upx-сжатие реально нужно, этап показан скорее для примера.
Для этапа «dmgbuild» я воспользовался скриптом make_dmg. Ему нужны права root, поэтому добавил скрипт в файл /etc/sudoers
Изменения в проектном файле и использование сторонних библиотек
В моём проекте используется libusb, а это далеко не часть Qt. Также необходимо было включить платформенно-зависимую реализацию HID. В проектный файл были добавлены строки:
В Mac OS X и Linux линкуемся с системной libusb, в Windows в зависимости от разрядности линкуемся с libusb-1.0-32.dll.a или libusb-1.0-64.dll.a. Помним, что .a-файл может быть переименован, но зависеть приложение всё-равно будет от libusb-1.0.dll. В Linux параметры для libusb берём через системную утилиту pkgconfig. Кроме libusb подключаем для каждой операционной системы необходимые системные библиотеки и иконки.
Удобно разнести итоговые файлы для разных операционных систем по директориям. Сделать это можно так:
Цель win64-x-g++ относится к win32, однако в проектном файле идёт последней и переписывает настройки.