Як налаштувати Qt для перехресної компіляції з Linux на цільову Windows?


82

Я хочу перехресно скомпілювати бібліотеки 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). Якщо я опускаю -xplatformопцію та встановлюю-platform мою цільову специфікацію (linux-win32-g ++), вона викликає перехресний компілятор, але тоді помилки, коли він виявляє, що деякі функції, пов'язані з Unix, не визначені.

Ось деякі результати моєї останньої спроби: http://pastebin.com/QCpKSNev .

Запитання:

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

  2. Якщо я використовую крос-компілятор mingw, коли мені доведеться мати справу з файлом специфікацій? Файли специфікацій для GCC для мене все ще є загадкою, тому мені цікаво, чи допоможе мені якийсь досвід тут.

  3. Загалом, що, окрім зазначення крос-компілятора в моєму qmake.conf, що ще мені потрібно розглянути?


2
Я вважаю, що для завантаження решти збірки потрібна локальна збірка qmake. див. також посилання на stackoverflow.com/questions/1025687/…
Мартін Беккет

Гаразд, це має сенс. Зараз я просто знайшов ще одну проблему, здається, я змішую рідні та перехресні ланцюжки інструментів. Помилка в моєму виведенні pastebin, здається, пов'язана з викликом x86_64-w64-mingw32-asзамість рідного.
Містер Шикаденс,

2
Я рідко позначаю SO-запитання як улюблене, але це було унікальне та цікаве запитання з крутою відповіддю.
jdi

Відповіді:


70

Просто використовуйте середовище M cross (MXE) . Це знімає біль з усього процесу:

  • Отримайте:

    $ git clone https://github.com/mxe/mxe.git
    
  • Встановіть залежності збірки

  • Побудуйте Qt для Windows, його залежності та інструменти перехресного складання; це займе близько години на швидкій машині з гідним доступом до Інтернету; завантаження становить близько 500 МБ:

    $ cd mxe && make qt
    
  • Перейдіть до каталогу вашого додатка та додайте інструменти перехресного складання до змінної середовища PATH :

    $ export PATH=<mxe root>/usr/bin:$PATH
    
  • Запустіть інструмент генератора файлів Qt, а потім складіть:

    $ <mxe root>/usr/i686-pc-mingw32/qt/bin/qmake && make
    
  • Ви повинні знайти двійковий файл в каталозі ./release:

    $ wine release/foo.exe
    

Деякі примітки :

  • Використовуйте головну гілку сховища MXE; схоже, це набагато більше любові від команди розробників.

  • Результатом є 32-розрядний статичний двійковий файл, який буде добре працювати в 64-розрядної Windows.


17
Примітка : ці інструкції стосуються Qt 4; для Qt 5 см stackoverflow.com/a/14170591
tshepang

Перед виконанням $ cd mxe && make qtслід встановити вимоги. Для систем Debian це означає sudo apt-get install autoconf automake autopoint bash bison bzip2 cmake flex gettext git g++ gperf intltool libffi-dev libtool libltdl-dev libssl-dev libxml-parser-perl make openssl patch perl pkg-config python ruby scons sed unzip wget xz-utils. Щодо інших систем, див. Mxe.cc/#requirements
Мартін Тома,

17

(Це оновлення відповіді @ Tshepang, оскільки MXE еволюціонував з моменту його відповіді)

Будівля Qt

Замість того, щоб використовувати make qtдля побудови Qt, ви можете використовувати MXE_TARGETSдля управління цільовою машиною та ланцюжком інструментів (32- або 64-розрядні). MXE почав використовувати .staticта .sharedяк частину цільового імені, щоб показати, який тип бібліотеки ви хочете створити.

# 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


Велике спасибі за оновлення. Також добре, якщо хтось, хто працює безпосередньо над проектом, відповідає.
tshepang

3
Це мало бути редагування / оновлення іншої відповіді, а не нової.
WhyNotHugo

3
@Hugo На сторінці редагування сказано: Як редагувати: ► виправити граматичні або орфографічні помилки ► уточнити значення, не змінюючи його ► виправити незначні помилки ► додати пов’язані ресурси або посилання ► завжди поважати оригінального автора. Це не один із них. Це продовження відповіді Чепанга.
Timothy Gu

Я не розумію цієї відповіді, коли я набираю "make qt ....", він просто відповідає "немає правила робити цільовий qt".
Шахта

5

Інший спосіб перехресного компілювання програмного забезпечення для Windows на Linux - це набір інструментів MinGW-w64 на Archlinux. Він простий у використанні та обслуговуванні, а також надає останні версії компілятора та багато бібліотек. Мені особисто це простіше, ніж MXE, і, схоже, швидше застосовувати нові версії бібліотек.

По-перше, вам знадобиться машина на основі арки (достатньо буде віртуальної машини або контейнера докера). Це не повинен бути Arch Linux, похідні теж будуть робити. Я використовував Manjaro Linux. Більшість пакетів MinGW-w64 недоступні в офіційних сховищах Arch, але в AUR є багато . Диспетчер пакунків за замовчуванням для Arch (Pacman) не підтримує встановлення безпосередньо з AUR, тому вам потрібно буде встановити та використовувати обгортку AUR, як yay або yaourt. Тоді встановити MinGW-w64 версію бібліотек Qt5 і Boost так просто, як:

yay -Sy mingw-w64-qt5-base mingw-w64-boost
#yaourt -Sy mingw-w64-qt5-base mingw-w64-qt5-boost #if you use yaourt

Це також встановить MinGW-w64 toolchain ( mingw-w64-gcc) та інші залежності. Тоді перехресне компілювання проекту Qt для Windows (x64) настільки просто, як:

x86_64-w64-mingw32-qmake-qt5
make

Для розгортання програми вам потрібно буде скопіювати відповідні dll з /usr/x86_64-w64-mingw32/bin/. Наприклад, вам зазвичай потрібно скопіювати /usr/x86_64-w64-mingw32/lib/qt/plugins/platforms/qwindows.dllв program.exe_dir/platforms/qwindows.dll.

Щоб отримати 32-бітну версію, вам просто потрібно використовувати її i686-w64-mingw32-qmake-qt5. Проекти на основі Cmake працюють так само легко x86_64-w64-mingw32-cmake. Цей підхід працював надзвичайно добре для мене, був найпростішим у налаштуванні, обслуговуванні та розширенні. Це також добре поєднується з послугами безперервної інтеграції. Також доступні зображення докера .

Наприклад, скажімо, я хочу створити графічний інтерфейс завантажувача субтитрів QNapi. Я міг зробити це за два кроки:

  1. Запустіть контейнер докера:

    sudo docker run -it burningdaylight / mingw-arch: qt / 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 .


Для розгортання вам потрібно скопіювати всі необхідні бібліотеки DLL Qt (або doc.qt.io/qt-5/windows-deployment.html ). Переконайтесь, що /mingw64/share/qt5/plugins/platforms/qwindows.dll копіюється на платформи / qwindows.dll.
develCuy

4

Добре, я думаю, я все зрозумів.

Частково базується на https://github.com/mxe/mxe/blob/master/src/qt.mk та https://www.videolan.org/developers/vlc/contrib/src/qt4/rules.mak

Схоже, що "спочатку" під час запуску configure (з -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 перелічує деякі параметри налаштування.


4

Для компіляції 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 ++' у всіх файлах make, які будують двійкові файли для вікон.

Нарешті, у вас можуть виникнути проблеми під час створення icd , що, мабуть, використовується для додавання підтримки ActiveX до Qt. Ви можете уникнути цього, передавши прапор -skip qtactiveqtсценарію налаштування. Я отримав це з цього звіту про помилку: https://bugreports.qt.io/browse/QTBUG-38223

Ось вся команда configure, яку я використовував:

    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, про обхідний шлях якої я також згадав.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.