Linux deploy qt как пользоваться

Обновлено: 07.07.2024

Пакетный выпуск приложений Qt под операционные системы Windows и Linux (сверхдетальный, супер понятный и всеобъемлющий, с картинками и текстами)

оглавление

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

1) Среда выпуска

  • win10 профессиональная версия
  • QT5.11
  • Qt Creator4.7.1
  • MinGw5.3.0 32bit

2) Метод однократной версии

Выпущенное таким образом приложение Qt поместит исполняемое приложение .exe Поместите его вместе с библиотекой динамической компоновки, от которой она зависит, в папку, скопируйте эту папку на клиентский компьютер (также доступный без среды разработки Qt), откройте исполняемое приложение и запустите его. Однако недостатком такого релиза является слишком большой размер файла релиза.

а) выпустить программу для выпуска

Во-первых, вам нужно запустить программу, которую вы хотите выпустить под Qt Creator через выпуск

После в каталоге хранилища проекта найдите теневую папку версии выпуска.

После входа в папку опубликуйте программу .exe Исполняемый файл, скопируйте его в место, которое легко найти, например на рабочий стол. Возьмите меня в качестве примера, скопируйте его на рабочий стол и создайте новый под названием Chat Папка

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

б) пройти windeployqt Bale

Если вы используете среду компиляции MinGw, то мы найдем файл с именем Qt5.11.2 for Desktop Инструмент командной строки


Дважды щелкните его, чтобы открыть и войти на рабочий стол, на котором хранятся исполняемые файлы. Chat Папка, используйте собственный инструмент упаковки Qt windeployqt Команда для упаковки библиотеки динамической компоновки в эту папку



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

3) Метод второй: публикация в автономном исполняемом exe-файле.

Как мы упоминали ранее, пакет файлов программы, выпущенной собственным методом Qt windeployqt, очень велик, и каждый класс имеет десятки мегабайт, что не способствует миграции, поэтому мы также можем использовать другие инструменты упаковки для интеграции библиотеки динамической компоновки.

Инструмент, который мы здесь используем, называетсяEnigma Virtual Box, Это интегрированное программное обеспечение для упаковки, само программное обеспечение не очень большое, всего несколько мегабайт размером, но, хотя воробей маленький и имеет все внутренние органы, он имеет все необходимые функции публикации, и посмотрите операцию, загрузите его на официальном сайте


б) упаковка

Следует отметить, что этот второй метод упаковки основан на первом способе упаковки через windeployqt Выше метода упаковки требуется первый шаг упаковочной папки. Итак, первый способ упаковки - это основной

Люди часто говорят no picture say jb , Итак, ниже приводится запись подробного изображения, откройте программное обеспечение Enigma Virtual Box, чтобы работать следующим образом




После завершения настройки выполните следующие действия.

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


Упакованное таким образом приложение намного меньше первого и представляет собой независимый исполняемый файл, который можно открыть напрямую, что намного удобнее.

4) Метод из трех упакованных в инсталляционный пакет для выпуска

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

а) Упаковано инструментом Inno Setup

б) Упаковано с помощью Advanced Installer Tool

1) Среда выпуска

  • deepin15.11
  • Qt 5.10.1
  • Gcc 64bit

2) Метод однократной посылки по скрипту

а) выпустить скомпилированный исполняемый файл

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






б) Написание файлов сценария

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

pack.sh : Используется для копирования динамической библиотеки, связанной программой, в папку для упаковки. Команда записывается следующим образом

picClient.sh : Имя сценария должно совпадать с именем программы, которая будет упакована и выпущена. Имя, которое я ввел здесь, - picClient , Так названный picClient.sh . Содержание команды написано следующим образом, менять не нужно


в) Выполните скрипт




  • Следует отметить, что последнее, что позволяет программе работать, - это скрипт, поэтому мы запускаем его напрямую. picClient.sh Этот скрипт обеспечивает успешное выполнение программы

г) Решите проблему xcb

Используйте вышеупомянутые шаги, чтобы упаковать папку, сжать ее в распакованный пакет и скопировать на целевой пользовательский компьютер для запуска.Если у другой стороны установлена ​​среда разработки Qt, она может работать успешно, но если у другой стороны нет операционной системы Ubuntu, тогда Подскажет Не удалось загрузить плагин xcb Проблема, как правило, такого рода проблема заключается в отсутствии двух динамических библиотек, зависимых от среды.

Это две ссылки.Вам необходимо использовать команды для просмотра файлов сущностей двух файлов, соответствующих разным версиям Qt (прямое копирование файла ссылки недопустимо), войдите в среду установки Qt под lib Библиотека в целом /Qt5.xx.x/xx.x/gcc_xx/lib Этот путь после ввода найти и скопировать в папку упаковки

Затем переименуйте две найденные зависимые библиотеки для связывания файлов, чтобы облегчить поиск скриптов.


, а затем выполните сценарий запуска, он не появится xcb Если сообщается об ошибке, упакованный файл можно скопировать на любой клиент Linux и успешно запустить (😄).

3) Метод два - развертывание и упаковка через Linuxdeployqt

а) Загрузите linuxdeployqt


Есть инструмент упаковки, который поставляется с Qt под окнами windeployqt , И есть такой инструмент развертывания под линуксом, но он не встроенный, он скомпилировал программные файлы на открытом GitHub, просто назовите егоlinuxdeployqt скачать

После загрузки дайте ему разрешение на выполнение программы, а затем перейдите к /usr/local/bin/ Каталог, переименовав его в linuxdeployqt, после завершения можно ввести linuxdeployqt -version Проверьте информацию о версии, если выводится информация о версии, это означает, что установка прошла успешно.


б) Настроить переменные среды версии Qt

Откройте терминал и введите vim

/.bashrc Command, а затем добавьте следующий контент о среде Qt в конец файла, который в основном необходимо заменить вашим собственным путем установки Qt

Затем выполните source

/.bashrc Команда для немедленного вступления измененной команды в силу без перезапуска


в) развертывание пакета


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

Напоминаем, что моя система слишком новая (Deepin 15.11😄), позвольте мне выбрать старую систему для использования linuxdeployqt , Посмотрев документацию, я обнаружил, что эта версия linuxdeployqt Поддерживаются только системы Linux ниже Ubuntu 16.04 и openSUSE 15.0


Я перешел на Ubuntu 14.1 и поменял его linuxdeployqt Version () также выполняется на этом шаге, отображается ошибка, указывающая, что файл значка не загружен.


Следовательно, вам необходимо удалить файл значка, созданный по умолчанию. default.jpg И повторно предоставьте один для этого logo.jpg В качестве примера, а затем сгенерируйте файл каталога default.desktop Переименуйте файл в picClient.desktop (Должно соответствовать имени исполняемого файла, который нужно упаковать), измените содержимое следующим образом

После завершения повторно выполнить linuxdeployqt picClient -appimage Команда, после того, как подсказка верна, она сгенерирует .AppImage Окончание файла


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


нота:Приложения, упакованные с помощью linuxdeployqt, не поддерживают миграцию исходного кода с Qt4 на Qt5, потому что среда компиляции отличается, Я также собирался напрямую скопировать исходный код программы, которую я хочу опубликовать в Deepin, на свой uUbuntu14, чтобы повторно использовать Qt для компиляции и использования linuxdeployqt Запаковал и обнаружил, что решить не удалось cannot execute binary file Позднее выяснилось, что эта проблема является причиной моей версии Qt, одна из которых - Qt4, а другая - Qt5, поэтому я могу только переписать простую демонстрацию в Ubuntu, чтобы выпустить демонстрацию.

Файлы упакованы таким образом, потому что linuxdeployqt Это экологичный продукт с открытым исходным кодом, поэтому он поддерживает работу в различных дистрибутивах Linux, что очень удобно. Вы также можете попробовать (😄😄)

Решил поднять вопрос о развертывании приложений написанных с использованием qt в Linux подобных системах.

Данная проблема легко решается в системах под управлением windows и mac так как разработчики фреймворка подготовили для этого специальные утилитки (windeployqt и macdeployqt)

Под Linux к сожалению нет официальной утилиты. По этому я решил заняться этой проблемой и написать утилиту для развертывания qt приложения под Linux.

Теперь немного описания:

Console-QtDeployer - это простая утилита аналогичная (windeployqt и macdeployqt) доступна здесь.

Данная утилита слинкована статически, а значит, все что вам нужно - это положить ее рядом со своим бинарником и вызвать ее, передав в качестве параметров путь к вашему приложению и путь к исходникам qt.

Давайте рассмотрим пример:

я написал простое qt приложение MyApp.
MyApp слинкована динамически - то есть для работы ему требуются библиотеки qt

После выполнения данной команды вы получите полностью готовое для работы приложение с готовым лаунчером который настроит все необходимое окружение для работы вашего приложения на всех машинах под управлением Linux.

Давайте подробнее рассмотрим некоторые из параметров CQtDeployer


help - Показать справку
always-overwrite - Копирует файлы с заменой уже существующих
-bin [params] Исполняемый файл над которым будет выполнятся деплой (в нашем случае это было -bin MyApp. Вместо MyApp можно указать путь к вашему приложению)
-qmlDir [params] - Папка qml. пример -qmlDir

/my/project/qml - папка с qml файлами вашего приложения, данная опция нужна для приложений использующих qml

deploy-not-qt - Копировать все библиотеки (не только qt данная опция может быть нужна для приложений которые должны использоваться на Linux системах с ограниченным количеством библиотек)
-qmake [params] Путь к qmake. пример (здесь нужно указать путь к тем библиотекам qt с которыми вы собирали ваше приложение в нашем случае это был qt 5.11.1 )
clear - удалит все старые файлы (с прошлого запуска)
-runScript [params] - установить новое имя результирующего файла (AppRun.sh по умолчанию)
пример -runScript myApp.sh

Вот и все Если есть какие то вопросы по использованию или проблемы то пишите мне буду рад помочь разобраться с ними.

Добрый день. входные данные:
Рабочая станция: Ubuntu 18.04 Среда разработки Qt5.12.1 Приложение GUI для работы с postgresql
Приложение собирается динамически. Для переноса на другую рабочую станцию написал небольшое приложение которое берет вывод ldd nameapp разбирает и копирует в папку lib в папке с приложением все необходимые библиотеки. Структура приложения получилась следующая

  • Myapp/ - папка приложения
    • myapp - приложение
    • myapp.sh - скрипт запуска приложения
      • lib/ - папка для библиотек
      • platforms/ - папка плагинов Qt5

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

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

      Как видно из вывода, единственная библиотека которая берется не из моей папки библиотек /lib64/ld-linux-x86-64.so.2 (0x00007fb898b4b000) эта ссылка указывает на библиотеку /lib/x86_64-linux-gnu/ld-2.27.so Это системная библиотека в 18 ubuntu ld-2.27.so в 16 ubuntu ld-2.23.so в Debian 8 ld-2.19.so.
      поэтому приложение и не работает на более старых системах. можно ли это как то обойти или единственный выход собрать приложение на более старой ОС , например 12 ubuntu ? Я так понимаю совместимость снизу вверх присутствует ?

      что мешает собирать нормальные пакеты под нужные версии дистрибутива? (собирать в докер контейнере)


      Проще всего сделать AppImage твоей программы, вместо этих выкрутасов.

      Тем более есть утилита, которая делает это условно в один клик:

      Буквально ./linuxdeployqt -appimage <app executable> .


      поэтому приложение и не работает на более старых системах

      А что пишет-то? Что-то вроде GLIBCXX_NOTFOUND ? Если да, то это проблема старой glibc, да. И пересобирать нужно либо на старой версии дистра, либо статически.

      на библиотеку /lib/x86_64-linux-gnu/ld-2.27.so Это системная библиотека в 18 ubuntu ld-2.27.so

      Не, это «интерпретатор», динамический линкер для ELF-файлов, это влиять не должно.

      Этот проект пока что поддерживает толко Qt5.9 на Qt5.12.1 не завелся.

      Я вообщето в линуксе новичок, так что пока это для меня сложновато. А разбираться банально нет времени. Вот сделал костыль и дальше пилить задачи.


      Если нужно таскать между разными версиями дистрибутивов, которые заранее не определены, и их больше 2-3, целесообразно собрать статикой и не таскать кучу либ. Будет в разы компактнее. И да, собирать это желательно на дистрибутиве постарше, чтобы не столкнуться с проблемой слишком нового glibc.

      Только LGPL внимательно читай. Если программа открытая, то пофиг. Если закрытая и пишется сугубо под себя, тоже пофиг. А если закрытая и ты делаешь её куда-то на сторону — то для статики надо обеспечить пользователю слинковать твою программу с другой версией Qt (простейший способ — предоставить объектники).

      Если же целевых платформ у тебя 1-2, целесообразно сделать сборку конкретно под них (например, в виртуалке), используя версии Qt из их репозиториев. Будет компактный пакет, зависящий от кутешного. Как, собственно, в линуксе и принято.


      целесообразно собрать статикой

      Только для этого ещё Qt нужно правильно собрать статически. В Windows, кстати, статический пакет с Qt ставится одной строкой, а в Linux мейнтейнеры популярных дистров пакета qt5-static не завезли.


      поддерживает толко Qt5.9 на Qt5.12.1 не завелся

      В очередной раз на хабре осталась незамеченной новость, которая пробежала в блоге Qt Labs и известила о выходе Qt Creator 2.3. Если вскользь просмотреть список изменений, то как обычно можно увидеть кучу прикольных плюшек, одна из которых заинтересовала меня неимоверно. А именно — развёртывание и отладка приложения на удалённой Linux-машине, при помощи ssh, прямиком из среды разработки.

      Почему мне это было интересно? Да потому что:
      1) У нас в конторе есть arm-железяка, для которой потихонечку пилится своя прошивка на базе Qt/Embedded+Linux.
      2) Кросс-компиляция, развёртывение и отладка очередной версии какой-либо из программ написанных с использованием Qt, как не сложно догадаться доставляет неимоверное удовольствие и сексуальное удовлетворение в виду необходимости использовать
      кучу самопальных скриптов типа build.sh, deploy.sh и прочее.
      3) Продуктивность понижается (а вот уровень раздражения повышается) и я даже начинал копаться в исходниках android-lighthouse чтобы стырить оттуда методику развёртывния пакетов на виртуальный Android-телефон… Слава богу не успел ничего написать).

      Что же нам предлагается? Как известно ранее в Qt Creator-е уже существовали средства для разворачивания приложений на Symbian (через USB-MicroUSB) и для Maemo (через ssh). Видимо в данной версии разработчики решили довести задумку до ума и засчёт унификации средства Maemo-деплоя позволить разворачивать приложения и на обычных Linux-машинах.

      • Интсрументарий — здесь можно указать компилятор. Конечно же как простой, так и кросс-компилятор.
      • Linux Devices — здесь указываются настройки развёртки собранного приложения на удалённой машине

      Изначальные условия:
      Основная Linux-машина, на которой стоит среда разработки Qt Creator 2.3 Beta, есть gdb и присутствуют исходники необходимой программы.
      Удалённое устройство с Linux, доступом по ssh и установленным gdbserver.
      Кросс-тулчейн для сборки (со скомпилированной Qt/Embedded конечно) и кросс-компилятор. Которые, к примеру, как в моём случае лежат ни разу не на той же машине где и исходники, а совсем даже на соседнем сервере). Что задачи нифига не облегчает… Но тем не менее буду объяснять именно на этом примере. В качестве инструментария используется buildroot, в качестве набора компиляторов — codesourcery. Платформа — ARM (armv7a).

      Итак, первое что стоит сделать, это спросить у qmake относящегося к кросс-скомпилированной версии Qt кое о чём… А именно, заходим на машинку, на которой у нас лежат средства кросс-сборки и выполняем примерно следующее:

      Это как бы намекает нам о местоположении нашей библиотеки. На всякий случай заглядываем в файлик

      Чтобы убедиться что тулчейн там указан вполне правильный:

      Следующий этап предварительной подготовки — смонтировать все необходимые каталоги по sshfs так чтобы тулчейну и прочим казалось что они никуда и не монтировались, а живут вполне себе припеваючи на той же машине где и должны находиться. Как несложно догадаться, смонтировать придётся 2 каталога: /root/codesourcery/ и /root/openaos/br11_glibc_building/

      Да, знаю, конечно немного некрасиво давать подобные права на рутовый каталог и вообще выглядит костляво… Но что поделать, когда разворачивали всю эту сборочную фигню, было мало опыта да и времени… А на виртуальной машинке чего бы и не пользовать рута было?

      image

      Ладно. Запускаем креатор и переходим в настройки. Первым делом, стоит указать путь до новоиспечённой Qt (что-то habrastorage на этом моменте помер, что меня поставило в ступор, но где наша не пропадала. ):

      По картинке ясно, что среда разработки нашла саму библиотеку и прочую фигню, но весьма расстроилась от того что не знает чем же всё это компилировать и где брать тулчейн. Объясним…

      image

      Для этого переходим в раздел «Инструментарии», добавляем новый компилятор типа GCC и заполняем необходимые поля — путь к компилятору и отладчику:

      image

      Последний штрих в диалоге настроек — надо бы добавить устройство, на котором мы хотим разворачивать наше приложеньице… нет ничего проще, переходим к разделу Linux Devices, жмякаем по кнопке «Добавить» -> «Generic Linux Device» -> заполняем поля мастера и завершаем настройку. Тут же появится окошко с тестом соединения.

      Что примечательно, если Вам не хочется иметь на удалённо машине пароль, можно сразу из интерфейса настройки соединения сгенерировать пару ssh-ключей и даже задеплоить публичный ключ на устройство. А затем преспокойненько удалить пароль или забыть пароль… Правда один баг здесь всё же присутствует. Записан публичный ключик будет в <каталог пользователя>/.ssh/authorized_keys и следовательно авторизация по ключам будет работать, если на устройстве установлен полноценный ssh-сервер, а не какой-нибудь dropbear к примеру. Стоит также обратить внимание на пункт «Тип устройства», который подсказывает, что ничто не мешает нам запустить наш удалённый Linux на виртуальной машине. Хотя конечно это и так понятно было…

      Жмякаем Ок и закрываем диалог настроек. Неужто всё? Фиг =)

      image

      Открываем проект, относящийся к железке, переходим на вкладку «Проекты» и меняем конфигурацию сборки на необходимую нам.


      В настройках запуска необходимо также внести изменения — добавить новую конфигурацию «Build Tarball and Install to Linux Host», в появившемся окне выбрать необходимые подпроекты, которые хотелось бы задеплоить, согласиться, пошариться по списку файлов для установки и если необходимо что-то поменять… Кстати, если хочется изменить пути установки неких файлов, то всё конфигурируется в файле проекта директивами типа:

      image

      Далее чуть ниже добавляем новый вариант запуска приложения — «имя_бинарника (remote)», дописать параметр к примеру "-qws", так как всё-же это приложение для Embedded версии библиотеки. Получается что-то вроде:

      Уже неплохо… Что дальше? Дальше — попробуем собрать! Редактор -> Сборка (Esc -> Ctrl+R). И ждём пока наше приложение соберётся. В моём случае это самая продолжительная процедура…

      Попили кофе? А теперь взгляните ка на вашу железку… Не появилось ли там окошко вашего приложения? Если всё собралось правильно, то уже должно бы…

      Вот только… Если в Вашем проекте помимо собственно приложений существуют так же и разделяемые библиотеки, то на этапе сборки tar-архива для заливки его на устройство может появитсья ошибка типа:

      image

      И наконец после окончательных исправлений, можно лицезреть окончательный лог среды разработки, который уже так и кричит о своей готовности:

      А лог запуска приложения радостно вопит:


      Собственно… Данный способ разворачивания приложений можно использовать не только для кросс-сборки или удалённого запуска, но и просто для автоматической сборки tar-архивов с дистрибутивами Ваших приложений. Для этого достаточно указать в качестве машины для развёртки IP хост-машинки и впилить необходимые инструкции установки в .pro файл. Это повышает удобство разработки к примеру QML-приложений, в которых всегда есть куча мелких файлов которые необходимо таскать за собой по пятам… А так, можно наконец не городить огород и для сборки дистрибутивов под linux использовать те же самые INSTALL-параметры из .pro файла, которые используются и при сборке дистрибутивов для Symbian.

      Вот такая фича, которая в очередной раз показывает что:
      а) разработка ПО может быть простой
      б) Разработчики Qt думают в первую очередь о своих пользователях (то бишь разработчиках, пользующих их продукт) и делают всё для повышения их продуктивности и привлекательности библиотеки в целом.

      Читайте также: