如何为 Linux 制作 Qt 应用程序的二进制发行版
我正在开发跨平台 Qt 应用程序。 它是免费软件，但不是开源的。 因此我想将它作为编译的二进制文件分发。
在 Windows 上没有问题，我将编译的 exe 与 MinGW 和 Qt 的 DLL 一起打包，一切都很顺利。
但在 Linux 上存在一个问题，因为用户的系统中的共享库可能与我的非常不同。
Qt 部署指南建议两种方法：静态链接和使用共享库。 第一个生成巨大的可执行文件，并且还需要 Qt 所依赖的许多库的静态版本，即我必须从头开始重建所有库。 第二种方法基于在应用程序启动之前重新配置动态链接器，对我来说似乎有点棘手。
谁能分享一下他/她在 Linux 下分发 Qt 应用程序的经验吗？ 我应该使用什么方法？ 我可能会遇到什么问题？ 还有其他方法可以完成这项工作吗？
I am developing cross-platform Qt application.
It is freeware though not open-source. Therefore I want to distribute it as a compiled binary.
On windows there is no problem, I pack my compiled exe along with MinGW's and Qt's DLLs and everything goes great.
But on Linux there is a problem because the user may have shared libraries in his/her system very different from mine.
Qt deployment guide suggests two methods: static linking and using shared libraries.
The first produces huge executable and also require static versions of many libraries which Qt depends on, i.e. I'll have to rebuild all of them from scratches. The second method is based on reconfiguring dynamic linker right before the application startup and seems a bit tricky to me.
Can anyone share his/her experience in distributing Qt applications under Linux? What method should I use? What problems may I confront with? Are there any other methods to get this job done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
共享库是可行的方法，但您可以避免使用
LD_LIBRARY_PATH（这涉及使用启动器 shell 脚本等运行应用程序）使用-rpath编译器构建二进制文件标志，指向您存储库的位置。例如，我将库存储在二进制文件旁边，或者存储在二进制文件旁边名为“mylib”的目录中。 要在我的 QMake 文件上使用它，我在
.pro文件中添加了这一行：并且我可以使用本地库覆盖任何系统库来运行我的二进制文件，并且不需要启动器脚本。
Shared libraries is the way to go, but you can avoid using
LD_LIBRARY_PATH(which involves running the application using a launcher shell script, etc) building your binary with the-rpathcompiler flag, pointing to there you store your libraries.For example, I store my libraries either next to my binary or in a directory called "mylib" next to my binary. To use this on my QMake file, I add this line in the
.profile:And I can run my binaries with my local libraries overriding any system library, and with no need for a launcher script.
您还可以在 Linux 上分发 Qt 共享库。 然后，让您的软件加载这些内容而不是系统默认的内容。 可以使用 LD_LIBRARY_PATH 环境变量覆盖共享库。 这可能是您最简单的解决方案。 您始终可以在可执行文件的包装脚本中更改此设置。
或者，只需指定用户需要在系统上安装的最低库版本。
You can also distribute Qt shared libraries on Linux. Then, get your software to load those instead of the system default ones. Shared libraries can be over-ridden using the
LD_LIBRARY_PATHenvironment variable. This is probably the simplest solution for you. You can always change this in a wrapper script for your executable.Alternatively, just specify the minimum library version that your users need to have installed on the system.
当我们在 Linux 上分发 Qt 应用程序（或者实际上任何使用共享库的应用程序）时，我们会提供一个目录树，其中包含实际的可执行文件和顶部的关联包装器脚本，以及包含共享库和您不需要的任何其他必要资源的子目录。不想链接。
这样做的好处是，您可以让包装脚本设置运行应用程序所需的一切，而不必担心用户设置环境变量、安装到特定位置等。如果完成正确的是，这也使您不必担心从哪里调用应用程序，因为它总是可以找到资源。
实际上，我们进一步采用了这种树结构，将所有可执行文件和共享库放置在平台/架构子目录中，以便包装器脚本可以确定本地架构并为该平台调用适当的可执行文件，并设置环境变量以找到适当的共享库。 我们发现这种设置在分发共享公共文件系统的多个不同 Linux 版本时特别有用。
话虽如此，我们仍然更喜欢尽可能静态构建，Qt 应用程序也不例外。 您绝对可以使用 Qt 静态构建，并且不必像 krbyrd 在他的回复中指出的那样构建大量额外的依赖项。
When we distribute Qt apps on Linux (or really any apps that use shared libraries) we ship a directory tree which contains the actual executable and associated wrapper script at the top with sub-directories containing the shared libraries and any other necessary resources that you don't want to link in.
The advantage of doing this is that you can have the wrapper script setup everything you need for running the application without having to worry about having the user set environment variables, install to a specific location, etc. If done correctly, this also allows you to not have to worry about from where you are calling the application because it can always find the resources.
We actually take this tree structure even further by placing all the executable and shared libraries in platform/architecture sub-directories so that the wrapper script can determine the local architecture and call the appropriate executable for that platform and set the environment variables to find the appropriate shared libraries. We found this setup to be particularly helpful when distributing for multiple different linux versions that share a common file system.
All this being said, we do still prefer to build statically when possible, Qt apps are no exception. You can definitely build with Qt statically and you shouldn't have to go build a lot of additional dependencies as krbyrd noted in his response.
sybreon 的答案正是我所做的。 您可以始终将库添加到LD_LIBRARY_PATH，也可以做一些更奇特的事情：为
每个目录设置一个附带的 Qt 库。 编写一个 shell 脚本，让它在可执行文件上运行 ldd 并运行 grep 来查找“未找到”，对于每个库，将适当的目录添加到列表中（我们称之为 $LDD）。 完成所有这些后，运行二进制文件，并将 LD_LIBRARY_PATH 设置为之前的值加上 $LDD。
最后是关于“我必须从头开始重建所有这些”的评论。 不，你不必这样做。 如果您有这些库的开发包，您应该有
.a文件，您可以静态链接这些文件。sybreon's answer is exactly what I have done. You can either always add your libraries to LD_LIBRARY_PATH or you can do something a bit more fancy:
Setup your shipped Qt libraries one per directory. Write a shell script, have it run
lddon the executable and grep for 'not found', for each of those libraries, add the appropriate directory to a list (let's call it $LDD). After you have them all, run the binary with LD_LIBRARY_PATH set to it's previous value plus $LDD.Finally a comment about "I'll have to rebuild all of them from scratches". No, you won't have to. If you have the dev packages for those libraries, you should have
.afiles, you can statically link against these.不是这样的答案（sybreon 涵盖了这一点），但请注意，如果您的二进制文件与 Qt 静态链接，则您不允许被允许分发它，除非您购买了商业许可证，否则您的整个二进制文件属于 GPL（或者你违反了 Qt 的许可证）。
如果你有商业许可证，没关系。
如果您没有商业许可证，您有两个选择：
动态链接 Qt v4.5.0 或更高版本（LGPL 版本 - 除开源应用程序外，您不得使用以前的版本），或者
打开您的源代码。
Not an answer as such (sybreon covered that), but please note that you are not allowed to distribute your binary if it is statically linked against Qt, unless you have bought a commercial license, otherwise your entire binary falls under the GPL (or you're in violation of Qt's license.)
If you have a commercial license, never mind.
If you don't have a commercial license, you have two options:
Link dynamically against Qt v4.5.0 or newer (the LGPL versions - you may not use the previous versions except in open source apps), or
Open your source code.
在 Linux 上创建 Qt 应用程序包的最简单方法可能是 linuxdeployqt。 它收集所有必需的文件，并让您构建一个在大多数 Linux 发行版上运行的 AppImage。
确保您在仍受支持的最旧的 Ubuntu LTS 版本上构建应用程序，以便您的 AppImage 可以列在 AppImageHub。
The probably easiest way to create a Qt application package on Linux is probably linuxdeployqt. It collects all required files and lets you build an AppImage which runs on most Linux distributions.
Make sure you build the application on the oldest still-supported Ubuntu LTS release so your AppImage can be listed on AppImageHub.
您可以查看 QtCreator 文件夹并使用它作为示例。 它在QtCreator/bin中有qt.conf和qtcreator.sh文件。
lib/qtcreator 是包含所有所需 Qt *.so 库的文件夹。 相对路径在 qtcreator.sh 中设置，应重命名为 you-app-name.sh
imports、plugins、qml 位于 bin 目录内。 它们的路径在 qt.conf 文件中设置。 这是 QML 应用程序部署所必需的。
You can look into QtCreator folder and use it as an example. It has qt.conf and qtcreator.sh files in QtCreator/bin.
lib/qtcreator is the folder with all needed Qt *.so libraries. Relative path is set inside qtcreator.sh, which should be renamed to you-app-name.sh
imports,plugins,qml are inside bin directory. Path to them is set in qt.conf file. This is needed for QML applications deployment.
本文包含有关该主题的信息。 我自己尝试一下：
http://labs.trolltech.com /blogs/2009/06/02/deploying-a-browser-on-gnulinux/
简而言之：
使用 –lsb-use-default-linker
这里需要一些调整，但我还没有尝试过，抱歉）
This article has information on the topic. I will try it myself:
http://labs.trolltech.com/blogs/2009/06/02/deploying-a-browser-on-gnulinux/
In a few words:
with –lsb-use-default-linker
need a few tweaks here but I haven't yet tried it sorry)