Как настроить 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.

вопросы:

  1. при кросс-компиляции чего-то вроде Qt для Windows с хоста Linux, должен ли собственный компилятор когда-нибудь вызывается? То есть, во время процесса кросс-компиляции, мы не должны использовать только кросс-компилятор? Я не понимаю, почему сценарий настройки Qt пытается вызвать собственный компилятор моей системы, когда я указываю .

  2. если я использую кросс-компилятор mingw, когда мне придется иметь дело с файлом спецификаций? Файлы спецификаций для GCC по-прежнему остаются для меня загадкой, поэтому мне интересно, поможет ли мне какой-то фон.

  3. в общем, за указание кросс-компилятора в моем qmake.конф, что еще мне нужно учесть?

5 73

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

так

  1. да

  2. только если вам нужно использовать что-то другое, чем msvcrt.dll файлы (по умолчанию). Хотя я никогда не использовал ничего другого, поэтому я не знаю наверняка.

  3. 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, например.