Я разрабатываю кросс-платформенное приложение Qt. Это бесплатная программа, хотя и не с открытым исходным кодом. Поэтому я хочу распространять его как скомпилированный двоичный файл.
В окнах нет проблем, я собираю скомпилированные exe вместе с MinGW и Qt DLL, и все отлично.
Но в Linux есть проблема, потому что пользователь может иметь общие библиотеки в своей системе, очень отличающиеся от моей.
Руководство по развертыванию Qt предлагает два метода: статическое связывание и использование разделяемых библиотек. Первый создает огромный исполняемый файл, а также требует статических версий многих библиотек, от которых зависит Qt, т.е. Мне придется перестроить все их из-за царапин. Второй метод основан на переконфигурировании динамического компоновщика непосредственно перед запуском приложения и кажется мне немного сложным.
Может ли кто-нибудь поделиться своим опытом распространения приложений Qt в Linux? Какой метод следует использовать? С какими проблемами я могу столкнуться? Существуют ли какие-либо другие методы для выполнения этой работы?
Вы также можете распространять общие библиотеки Qt в Linux. Затем загрузите ваше программное обеспечение, чтобы загрузить их вместо системных по умолчанию. Общие библиотеки могут быть перегружены с помощью переменной среды LD_LIBRARY_PATH. Это, наверное, самое простое решение для вас. Вы всегда можете изменить это в оболочке script для своего исполняемого файла.
В качестве альтернативы просто укажите минимальную версию библиотеки, которую ваши пользователи должны установить в системе.
Доступны общие библиотеки, но вы можете избежать использования LD_LIBRARY_PATH (который включает запуск приложения с использованием оболочки запуска script и т.д.), построив ваш двоичный код с флагом компилятора -rpath, указав там, где вы сохраняйте свои библиотеки.
Например, я храню свои библиотеки либо рядом с моим двоичным файлом, либо в каталоге под названием mylib рядом с моим двоичным кодом. Чтобы использовать это в моем файле QMake, я добавляю эту строку в файл .pro:
QMAKE_LFLAGS += -Wl,-rpath,\\$\$ORIGIN/lib/:\\$\$ORIGIN/../mylib/
И я могу запускать свои двоичные файлы с моими локальными библиотеками, переопределяющими любую системную библиотеку, и без необходимости запуска launcher script.
Когда мы распространяем приложения Qt на Linux (или действительно на любые приложения, использующие разделяемые библиотеки), мы отправляем дерево каталогов, которое содержит фактическую исполняемую и связанную с ней обертку script вверху с подкаталогами, содержащими разделяемые библиотеки и любые другие необходимые ресурсы, с которыми вы не хотите связываться.
Преимущество этого заключается в том, что вы можете иметь оболочку script настроить все, что вам нужно для запуска приложения, не беспокоясь о том, что пользователь установил переменные среды, установил их в определенное место и т.д. Если все сделано правильно, это также позволяет вам не беспокоиться о том, откуда вы вызываете приложение, потому что он всегда может найти ресурсы.
Мы фактически используем эту древовидную структуру еще больше, разместив все исполняемые и разделяемые библиотеки в подкаталогах платформы/архитектуры, чтобы оболочка script могла определить локальную архитектуру и вызвать соответствующий исполняемый файл для этой платформы и установить среду переменные, чтобы найти соответствующие общие библиотеки. Мы обнаружили, что эта настройка особенно полезна при распространении для нескольких разных версий Linux, которые используют общую файловую систему.
Все это говорит о том, что мы по-прежнему предпочитаем строить статически, когда это возможно, Qt-приложения не являются исключением. Вы можете определенно строить с Qt статически, и вам не нужно будет строить много дополнительных зависимостей, как отметил krbyrd в своем ответе.
Не ответ как таковой (sybreon покрыл это), но учтите, что вам не разрешено распространять ваш двоичный файл, если он статически связан с Qt, если вы не купили коммерческую лицензию, иначе все ваши двоичные файлы попадают под GPL (или вы нарушаете лицензию Qt.)
Если у вас есть коммерческая лицензия, неважно.
Если у вас нет коммерческой лицензии, у вас есть два варианта:
Динамически связывайтесь с Qt v4.5.0 или новее (версии LGPL - вы не можете использовать предыдущие версии, кроме приложений с открытым исходным кодом) или
Откройте исходный код.
ответ sybreon - это именно то, что я сделал. Вы можете всегда добавлять свои библиотеки в LD_LIBRARY_PATH, или вы можете сделать что-то более интересное:
Настройте отправляемые Qt-библиотеки по одному каталогу. Напишите оболочку script, запустите ldd в исполняемом файле и grep для 'not found', для каждой из этих библиотек добавьте соответствующую директорию в список (позвоните по этому адресу $LDD). После того, как вы их всех, запустите двоичный файл с LD_LIBRARY_PATH, установленным для него предыдущим значением плюс $LDD.
Наконец, комментарий о "Мне придется перестроить все из них с царапин". Нет, вам не придется. Если у вас есть пакеты dev для этих библиотек, у вас должны быть файлы .a, вы можете статически ссылаться на них.
Вы можете посмотреть в папку QtCreator и использовать ее в качестве примера. Он имеет файлы qt.conf и qtcreator.sh в QtCreator/bin.
lib/qtcreator - это папка со всеми необходимыми библиотеками Qt *.so. Относительный путь устанавливается внутри qtcreator.sh, который должен быть переименован в you-app-name.sh
импорт, плагины, qml находятся внутри каталога bin. Путь к ним задается в файле qt.conf. Это необходимо для развертывания приложений QML.
В этой статье содержится информация по этой теме. Я попробую сам: http://labs.trolltech.com/blogs/2009/06/02/deploying-a-browser-on-gnulinux/
В нескольких словах: