Поищи информацию про Cygwin

ты хочешь собирать на линухе, и потом пускать под вендой? Забей, проблем там будет более чем до жопы. В общем с Qt4 такая херня работала четь более, чем никак. Под винду все эти поделки надо собирать студийным компилятором, чтоб именть минимум проблем на всем зоопарке оффтопика.

Анончик, ты не в ту степь зашёл. Ему нужен обычный MinGW-w64.

Какие могут быть подводные камни, если учесть, что я работаю в том числе с Windows-специфичными компонентами Qt (например, Active Qt)?

C QtAx не работал, но обычные приложения вполне себе нормально кросс-компилируются.

Подводные камни могут быть в Wine, кстати, раз используешь ActiveX.

В общем с Qt4 такая херня работала четь более, чем никак.

Кросс-компилировал с помощью MinGW-w64 Qt 4 приложение под Windows, причём статикой. Всё было просто отлично. И работало на всех Windows, начиная с 2000. Чтобы добиться такого же эффекта с помощью студийного компилятора, надо ещё постараться.

Есть желание настроить кросс-компиляцию по Wine

Т.е. используя виндовый компилятор, запущенный под Wine? Это не совсем кросс-компиляция. Кросс-компиляция - это когда используешь кросс-компилятор, который есть нативный бинарник, генерирующий код для другой ненативной платформы.

Ну да. Порт gcc (mingw) под Windows запущенный под эмулятором Windows, который работает под Linux.

Полноценной кросс-компиляции без Wine, насколько я понимаю, в моем случае достигнуть очень сложно.

Порт gcc (mingw) под Windows запущенный под эмулятором Windows, который работает под Linux.

Такой вариант - это если ничего другого не помогает.

Полноценной кросс-компиляции без Wine, насколько я понимаю, в моем случае достигнуть очень сложно.

Не очень. mingw-w64 с соответствующим компилятором имеются. Qt тоже. Даже последней версии 5.7. Это из проекта MXE.cc, которым можно пользоваться под разными дистрибутивами ГНУ/Линукса. В Федоре (5.6) и Арче (5.7) Qt есть из-коробки. В Дебиане по крайней мере кросс-компилятор.

MXE.cc - не знал о таком, благодарю.

Попробую завести, но пока сомневаюсь насчет Active Qt и прочей win-ерунды.

Есть желание настроить кросс-компиляцию по Wine.

Это не кросс-компиляция.

Для кросс-компиляции есть MXE.

работаю в том числе с Windows-специфичными компонентами Qt (например, Active Qt)?

В этом списке qtactiveqt отмечен как собирающийся для всех четырёх возможных целей - 32/64 бита и shared/static.

Active Qt и прочей win-ерунды.

Так компилятору это пополам. Если используется не самое-распоследнее WinAPI, которого нет в mingw-w64. Но тогда тот же mingw-w64 компилятор только под Wine - это тоже самое. (Иначе только запускать под Wine оригинальный VC, что мне в консоли удалось, а вот студия не взлетает). А вот запустить скомпилированное только под Wine и можно.

Отлично, буду пробовать.

ты хочешь собирать на линухе, и потом пускать под вендой? Забей, проблем там будет более чем до жопы.

ЩИТО?

Как раз только и исключительно в этом случае никаких проблем под любой виндой не будет. Поделки под винду собирать можно и нужно только кросс-компиляцией gcc-mingw под линухом. Отлаживать и тестировать под wine. Только это может гарантировать работу на всём зоопарке оффтопика. За over 15 лет эта методика вообще ни разу не подводила. Собранные под линухом бинарники для винды работают всегда и везде без каких-либо проблем.

Все эти вижуалстудии и прочий шлак - убогое, несовместимое даже с собой говнище, использование которого порождает массу проблем, начиная от dll-hell (особенно с плюсами) и заканчивая трудноотлавливаемыми ошибками самого студийного компилятора, количество которых только увеличивается от версии к версии.

Причём тут кросс-компиляция к Wine? Ты путаешь понятия.

За over 15 лет эта методика вообще ни разу не подводила.

Лорчую.

Собранные под линухом бинарники для винды работают всегда и везде без каких-либо проблем.

Это заслуга MinGW. У меня прога собранная им, даже на Windows 98 работала без проблем.

Есть желание настроить кросс-компиляцию по Wine

Кросс-компиляция и Wine не связаны вообще никак.

Тебе нужно:

1. поставить на линукс gcc-mingw(32|64)

2. собрать им Qt или взять уже собранный под винду Qt и положить его заголовки на видное для компилятора место.

3. Собрать свой проект используя gcc-mingw(32|64) под линуксом и получить виндовый бинарник.

4. (Опционально) Проверить работу собранного бинарника под Wine. Если работает под Wine - то будет работать в любой винде. Только для этого пункта Wine и понадобится.

5. (Опционально) Упаковать твой проект при помощи NSIS собранного под линукс под линуксом же, с целью получить няшную виндовую инсталляшку.

Если работает под Wine - то будет работать в любой винде.

Это не всегда верно, wine - это не точная копия Windows поэтому беспроблемная работа программы в wine ещё не гарантирует на 100% беспроблемную работу в реальной Windows.

Это не всегда верно,

Практика показывает, что это верно всегда. Потому что Wine реализует лишь часть WinAPI, которая гарантированно есть в любой винде, причём без всяких недокументированных, полудокументированных, недодокументированных и пр. фич. Если ты заставил свою софтину корректно работать под Wine, то она не может не работать под виндой.

Есть отдельные тонкости, типа multiselect в TreeView который то вкидывают, то выкидывают из винды, например, но это и под виндой никак не обойдёшь, так что даже в этом случае Wine как минимум не хуже винды для отладки, кроме того, позволяет версиеспецифичные фичи проверить не отходя от кассы, просто меняя настройку Wine, а не занимаясь онанизмом с загрузкой 100500 вариантов венды.

Практика показывает, что это верно всегда.

Практика показывает как-раз ровно обратное, а причина в том что wine не идентична на 100% оригиналу.

Практика показывает как-раз ровно обратное

Пример кода который работает под Winе, но не работает под виндой - в студию. Разумеется код не должен содержать Wine-специфичных функций, которых нет в официальной документации на WinAPI.

5. (Опционально) Упаковать твой проект при помощи NSIS собранного под линукс под линуксом же, с целью получить няшную виндовую инсталляшку.

Юзаю Qt Installer Framework и доволен.

Кстати, NSIS как раз прекрасно собирается под Linux'ом на Win.

А вот Qt Installer только на родной платформе (если там, конечно, никаких апдейтов не вышло).

Любителям экзотики

Я как-то рассматривал вариант «накатить ReactOS в VirtualBox» и на последний уже себе спокойненько ставить Qt SDK. Теоретически вариант хорош тем, что хостовый линукс ничем, кроме собственно виртуалбокса, загаживаться не будет, а в виртуалке сразу получаем среду и для компиляции, и для начального тестирования.

На практике обнаружилось, что инсталлятор Qt сжирает все системные ресурсы гостевой системы (ReactOS 0.4) и вешает её. (Я наращивал память виртуалки, но где-то, кажется, на 2 Гб добился того, что вместо зависания ОС просто начал выпадать синий экран.) Похоже, там менеджер памяти до сих пор не вылизан полностью. Возможно, проблему удастся решить, подсунув реактосу уже распакованную Qt, но мне стало банально лень, и я решил вернуться к этому вопросу как-нибудь в другой раз.

Ну и в любом случае пока что ReactOS существует только в 32-разрядном виде, что для компиляции под винду образца 2016 года довольно-таки уныленько.

Там скромненько так пропущен qtwebengine, а всё почему? А потому что хромиум только студией собирается, млин.

Там скромненько так пропущен qtwebengine

Причём тут скромненько? В том списке отображаются только поддерживаемые пакеты, за более подробной информацией можно обратиться к git log. https://github.com/mxe/mxe/issues/1509

Че-то с MXE как-то сложнее, чем руками.

GDB нет, webview по умолчанию не собрался и т.д.

webview по умолчанию не собрался

Точнее собрался, но qmake его почему-то не видит.

GDB нет

http://mxe.cc/build-matrix.html тут GDB есть.

Шаги указанные в http://mxe.cc/#tutorial выполнены? В частности этот шаг:

Step 4: Environment Variables
Edit your .bashrc script in order to change $PATH:
export PATH=/where MXE is installed/usr/bin:$PATH

qmake его почему-то не видит.

У MXE свой qmake как и всё остальное, смотри в каталоге

$MXE_DIR/usr/$(TARGET)/

Че-то с MXE как-то сложнее, чем руками.

Как использовать MXE в своих проектах для следующих систем сборки: Autotools, CMake, Qt, Makefile, OSG разбирается в шаге 5 http://mxe.cc/#tutorial

Можно глянуть как это делает товарищ Moritz Bunkus со своим mkvtoolnix

Там gdb.exe собирается.

Да.

webview по умолчанию не собрался

А по ходу я зря на MXE ругался. Сейчас поставил Qt 5.7.0 с помощью инсталлятора на винде - та же фигня «Unknown module(s) in QT: webview».

Я слоупок по ходу. Webkit-то небось только под x64 работает...

Даже дело не в этом, а вот в этом:

On Windows, Visual Studio 2013 or Visual Studio 2015 is required.

Короче говоря, не будет кросс-компиляции.

Я когда-то пытался замутить такое. Тормоза при сборке больше чем в оффтопике. Не выдержал - продолжаю использовать оффтопик по удаленке для сборки релиза и предрелизного тестирования.

Статикой собирать - за Qt платить. Не все могут так запросто выбить пару штук баксов с начальства на такие вещи.

У меня OSS-приложение. Тот же qbittorent и Telegram собирают статикой Only.

Тогда норм. Но «OSS-приложение» звучит как «в этом ITT треде».

Webkit-то небось только под x64 работает

Нетъ.

И учти что «webview» - это http://doc.qt.io/qt-5/qtwebview-index.html, а не что-то другое

Статикой собирать - за Qt платить

Читай LGPL

Короче говоря, не будет кросс-компиляции.

Если тебе не приницпиально использовать именно QtWebEngine, то можешь попробовать собрать QtWebKit из https://github.com/annulen/qtwebkit-snapshots (ветка build_build). Возможные проблемы:

1) вряд ли получится использовать для сборки рецепт из mxe, по крайней мере без его доработки

2) потребуются определенные допилки в системе сборки проекта, так как предполагается, что сборка под винду происходит на виндовом хосте, в частности что шелл - это cmd.exe

Если тебе не приницпиально использовать именно QtWebEngine, то можешь попробовать собрать QtWebKit из https://github.com/annulen/qtwebkit-snapshots

QtWebKit есть в MXE вообще-то.

И учти что «webview» - это http://doc.qt.io/qt-5/qtwebview-index.html, а не что-то другое

Про него и говорю.

Короче говоря, я вернулся на виртуалки в Azure. Иначе слишком много геммора. А если учесть, что часть проектов на Qt 5.6 и часть уже на 5.7, то вообще весь этот зоопарк руками сложно разруливать.

Про него и говорю.

Можно добавить в WebView поддержку QtWebKit, тогда этот модуль можно будет юзать с mingw

Я и говорю что с новым qtwebkit'ом этот мейкфайл не заведется без правок