QT Статика

Чтобы слелать статическую сборку проекта на Qt нужно сначала статически собрать саму Qt. Или установить пакетным менеджером уже собранную статически кем-то добрым Qt.

И смотря под какую ОС.

Если для Linux - FBSD, то берёшь инструкцию по сборке статического варианта, пакетным менеджером ставишь все нужные dev-пакеты и собираешь. Положить лучше в opt.

Если под винду и MSVS то тут надо самому собирать по миру требуемые для сборки 3rd библиотеки, компилять их и собирать статический Qt. В общем запаришься. Либо поставить MSYS2 и там уже есть готовый откомпилированный пакет qt5_static и qt6_static. Нужно только установить и скормить путь до пакета QtCreator. В принципе, под MSYS2 можно, как и под Linux скомпилировать Qt статически самостоятельно. Все пакеты поставить менеджером.

Также можно использовать Gygwin, и самому, опять же, собрать статический вариант Qt.

Ты хочешь собрать библиотеку Qt из исходников в качестве статической библиотеки?

Я хочу собирать проект без зависимостей. Без динамических библиотек. Делать это как можно удобнее и кроссплатформенно.

Чтобы слелать статическую сборку проекта на Qt нужно сначала статически собрать саму Qt.

Удваиваю, это правильная постановка вопроса.

Я делал под винду. Вот мои примеры: Qt4 (zvyozdochkin.ru), Qt5 (zvyozdochkin.ru).

Под линукс меня всегда устраивала Qt из репозиториев, но всё чаще задумываюсь, что надо бы и в линуксе сделать статику и оборачивать свой проект в AppImage. Теоретически в линуксе это должно быть НАМНОГО проще.

И это такая область, где любые инструкции надо не просто прочесть, а понять и адаптировать к тому, что нужно тебе. Начиная с того, чтобы определиться с нужными модулями.

P.S. Правильное название фреймворка - Qt. Под QT обычно понимают Apple QuickTime.

Делать это как можно удобнее и кроссплатформенно.

При сборке самой Qt (а это, как тебе уже написали, первый необходимый шаг) особенности платформ учесть всё же придётся. Но это при благоприятном стечении обстоятельств достаточно сделать единожды.

А сборка твоего проекта — да, ничем не будет отличаться от обычной, просто укажешь путь к нужной qmake.

А нет уже готовых собранных QT для скачивания?

Тебе же сказали: Qt. А ты всё равно QT. Idiots test fail.

Кто ж за тебя догадается, какие модули тебе нужны?

А если собирать её по максимуму — у тебя в исполняемом файле будет монстр.

И ещё не забывай про лицензионные ограничения. Если ты делаешь что-то проприетарное, берёшь Qt под лицензией LGPL и каким-то образом распространяешь, ты должен дать законному получателю твоего продукта возможность заменить твою сборку Qt на другую. Способы разные: либо передаёшь ему свои исходники (необязательно под свободной лицензией), либо свои объектные файлы… либо используешь только динамическую линковку. Последний способ обычно самый простой, поэтому часто пишут «хотите использовать LGPL — не связывайтесь со статикой» (в общем случае это утверждение неверно, но для ЛПРов так понятнее).

А если собирать её по максимуму — у тебя в исполняемом файле будет монстр.

LTO?

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

А вот собирать библиотеку Qt в статическом виде, особенно в винде - это очень нетривиальная задача.

Возьми обычную сборку с динамическими библиотеками и упакуй в AppImage. В результате у тебя будет один файл. А статика это костыль.

С большой вероятностью идя по этому пути, он получит куда более жирный дистрибутив, чем со статикой. Как решается «нетривиальная задача» статической сборки именно под винду, я ему ссылок накидал.

LTO?

Не распарсил аббревиатуру. Хочешь сказать, что компилятор выкинет всё неиспользуемое? Возможно, так оно и будет. Но я бы на это не полагался.

Не распарсил аббревиатуру.

Link-Time Optimization

Хочешь сказать, что компилятор выкинет всё неиспользуемое?

Угу.

Возможно, так оно и будет. Но я бы на это не полагался.

О, а я думал это я мистик-параноик. =) Если и статический Qt собрать с -flto, и прилагу на нём – всё должно быть пучком.

UPD. Ну, разве что сам Qt внутри себя высокосвязанный и протащит дохренища своего барахлишка даже при минимальном использовании.

Ну, разве что сам Qt внутри себя высокосвязанный и протащит дохренища своего барахлишка даже при минимальном использовании.

По идее не должно быть, но вот это бы надо проверять экспериментально. Ну и скорость сборки, думаю, будет зависеть от объёма библиотек.

В любом случае я вот свою сборку сделал без WebEngine и не пожалел об этом. Виндовые сборки DoubleContact именно на этой культе ручной сборки и базируются. А вот ТС… вдруг ему именно этот самый энджин и нужен?

Ну и скорость сборки, думаю, будет зависеть от объёма библиотек.

-flto=`nproc`

:)

В любом случае я вот свою сборку сделал без WebEngine и не пожалел об этом.

Ух! Нашёл про что вспомнить. Ясен хрен что QtWebEngine это монстр, собирающийся почти столько же сколько сам хромиум, т.е. во много раз дольше всего остального Qt вместе взятого.

А вот ТС… вдруг ему именно этот самый энджин и нужен?

«Поплачь о нём, пока он живой…» Ну тогда и статическая линковка ему не поможет: WebEngine протащится весь, а на его фоне всё остальное будет как маленькая писюлька.

Не пользуйся культяпками, мой тебе совет! И твои утилиты не будут жирными, тормозными и ублюдско выглядящими! Посмотри в сторону nuklear и подобных header-only GUI-библиотек. Они легковесные и имеют множество всякого разного бэкграунда.

А нет уже готовых собранных QT для скачивания?

Да, есть под Windows. Например, вот: https://packages.msys2.org/search?q=qt+static

По Linux такое наверное не завезли и придётся страдать целый день с многочасовым конфигурированием и компиляцией Qt.

Посмотри в сторону nuklear и подобных header-only GUI-библиотек.

Список «подобных» в студию, плиз. Недавно тут кто-то упоминал nuklear (может и ты же), глянул, но пока что чисто для эрудиции что есть такое.

UPD. Я б предпочёл что-нибудь легковесное, но на C++.

С Qt этр вроде нереально. QPA – всё равно .soшки, даже если сами не имеют зависимостей

Как решается «нетривиальная задача» статической сборки именно под винду, я ему ссылок накидал.

К большому сожалению большинство наших инструкций давным давно устарело и они имеют разные недостатки, вроде:

Для работы наших программ по-прежнему нужны библиотеки mingwm10.dll и libgcc_s_dw2-1.dll. Возможно, их тоже можно как-то слинковать статически, но как - я ещё не разобрался. Впрочем, они небольшие и погоды не делают.

К слову это лечится либо флагом -static-libgcc, либо конструкцией вида:

QMAKE_LFLAGS = -static -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc

В 2022 году наиболее беспроблемный способ заиметь статическую сборку Qt на Windows за 10 минут, а не за два дня, это использовать MSYS2 в котором добрые и заботливые люди уже давно приготовили пакеты qt5-static и qt6-static и даже обновляют их постоянно.

Ну а в Linux-дистрибутивах лучший вариант это использование FlatPak или Snap, либо нативного пакета под свой дистр без какой-либо статики. AppImage слабо подходит, потому что наплевательски относится к тем же темам Qt в дистрибутиве.

С Qt этр вроде нереально. QPA – всё равно .soшки, даже если сами не имеют зависимостей

Там вроде для статической сборки нужно ещё было править сами исходные файлы своей программы, добавляя в них конструкции вида:

Q_IMPORT_PLUGIN(QXcbIntegrationPlugin)

Как раз связанные с QPA. В общем, статическая сборка это всего боль и компромиссы.

К слову это лечится либо флагом -static-libgcc, либо конструкцией вида

О, спасибо! К сборке самой Qt этот флаг тоже надо применить или достаточно собирать с ним свой проект?

Желательно к сборке Qt, но можно и для самого проекта указать, если лень Qt пересобирать. По идее работать и так и так должно.

Можешь попробовать добавить qt пакет из conan (в conan-center уже есть куча собранных пакетов для различных конфигурацию, поэтому есть вероятность его не собирать) и установить self.options["qt"].shared = False. Однако надо помнить, что при линковке статически не открытых проектов с Qt есть большая вероятность выстрелить себе в ногу.

Спасибо EXL за советы, надо попробовать.

Ну и сколько по твоему значит «более жирный»? Мегабайт 50-100 ? Вряд ли он использует ВСЕ компоненты Qt в своем приложении. А сколько ты сэкономишь при статической сборке?

Недавно тут кто-то упоминал nuklear

UPD. Я б предпочёл что-нибудь легковесное, но на C++.

https://github.com/ocornut/imgui

Любопытно, сенькс.

самому собирать по миру требуемые для сборки 3rd библиотеки Все там есть уже в паке исходников. Нужен только питон и перл для выполнения скриптов сборки.

Откуда вы беретесь специалисты, которые на Qt только хелоуворлды писавшие. Никаких тормозов нет. Если говорить про размер - 50-100Мб это много?

Если говорить про размер - 50-100Мб это много?

Смотря для чего. DoubleContact, собранный статикой под винду, с Qt4 занимает 10 мегабайт, с Qt5 — ближе к 20. Это exe-файл, внутри которого уже все нужные ему части Qt. Так что по мне — да, 50-100 это многовато.

Под линукс, как я уже выше писал, я пока собирал только динамикой (в releases есть DEB).

DoubleContact, собранный статикой под винду, с Qt4 занимает 10 мегабайт, с Qt5 — ближе к 20

Ну хз. По моему ИМХО для винды программа, которая весит 50-100Мб - это вообще мелочь.

Вот некоторый перечень ПО для винды с указанием занимаемого объема:

• CMake 93Mb;
• DeadBeef 111Mb;
• Doxygen 126Mb;
• Gimp2 1200Mb;
• Google Chrome 809Mb;
• Git 270Mb;
• Libreoffice 728Mb;
• Notepad++ 11Mb;
• qBittorrent 137Mb;
• TeamViewer 123Mb;
• Telegram 178Mb;
• Typora 232Mb.

Это я к тому, что может не стоит париться из-за 50-100Мб.

Кстати, интересно, что похоже qBittorrent собран статически, вот содержимое каталога:

• qbittorrent.exe 27Mb;
• qbittorrent.pdb 105Mb;
• qt.conf 84b;
• uninst.exe 142kb;
• translations/ (каталог) 5Mb.

Нахрена только файл с отладочными символами положили в дистрибутив.

и тут на фоне всеобщего воодушевления от gcc и msys2, под оффтопиком появляется libwinpthread и помножает попытки сделать статик на ноль. Вот такой вот будет хитрый статик, с отдельными dll :-)

«static libwinpthread» это отдельная «война и мир»

Нахрена только файл с отладочными символами положили в дистрибутив.

Да многие кладут. Наверное потому что в случае Memory Access Violation тогда будет более внятный backtrace и пр.

и тут на фоне всеобщего воодушевления от gcc и msys2, под оффтопиком появляется libwinpthread и помножает попытки сделать статик на ноль. Вот такой вот будет хитрый статик, с отдельными dll :-)

«static libwinpthread» это отдельная «война и мир»

Обычный -static разве не решит эту проблему? Да и тут вот вроде как предлагают разные решения: https://stackoverflow.com/questions/13768515/how-to-do-static-linking-of-libwinpthread-1-dll-in-mingw

Обычный -static разве не решит эту проблему? Да и тут вот вроде как предлагают разные решения

обычный -static и static-libgcc не решают это проблему. И обилие предлагаемых обходных решений как-бы намекает, что дело тут нечисто

перепробовав разные варианты, пришёл к выводу что есть в офтопике вещи которые нельзя делать статикой. Иначе оно в лучшем случае начинает глючить при дальнейших обновлениях ОСь :-) вот winpthread одно из них.

подозреваю что модули Qt работающее с COM или крипто-дрм тоже так-же, лучше оставить динамикой как dll

добавление про winpthread: если вкорячить его статикой, то может (не пробовал, но скорее всего так и будет) отвалится механизм плагинов, сиречь прочей динамической загрузки. Или каждому плагину так-же на уровне заклинаний линкера придётся объяснять «где сидит фазан»