I got an app, that is ready to release. On windows, I simply type 'windeployqt.exe MyApp.exe' inside 'release' folder of app build in special qt cmd. I'm trying to do the same on kali linux (I dont have time to install other deb based distro). I'm searching for solution for three hours, and I cant find anything good. So, how to make application executable on other linux computer without Qt Creator installed?
There are many ways to deploy Qt applications on Linux. AppImage created with the help of linuxdeployqt or linuxdeploy-plugin-qt is one option, perhaps even the simplest one but it has its drawbacks. From my personal experience I can think of two:
Your app won't generally be able to use native icon/font/other themes.
Sometimes your AppImages might occasionally cease to work due to some unexpected system update which would, for example, break the binary compatibility of OpenSSL libraries.
Other packaging options for Linux include:
Linking the application with static version of Qt. It is the
approach used e.g. by Telegram. The instructions can be found
here.
Beware, however, that using this approach for commercial closed
source applications generally requires commercial Qt license.
Probably it is possible to get away with LGPL but it would be very
cumbersome: you'd have to provide customers with compiled object
files so that they can replace them and re-link the app. Also beware
of the fact that if the application you intend to create is going to
be an open source one, the maintainers of Linux distributions would
generally not agree to distribute statically linked applications -
that violates the basic rules for many distros according to which
applications should not bundle their dependencies but instead should
use the system provided libraries. It is important from e.g.
security perspective - if some security threat is found in Qt in
future, it can be fixed within a Qt library itself and all
applications using that library would then also be secure -
something not that easily achievable with application built with
static version of Qt.
Creating native packages for target systems - i.e. deb packages for
Debian/Ubuntu systems and their derivatives, rpms for Fedora,
OpenSUSE and other rpm-based distros,
PKGBUILD for Arch
Linux and various other kinds of packages for various other distros,
hundreds of them. The advantage is good integration with the rest of the system: native themes etc. Also you get all the advantages of the security fixes for shared libraries.
Using flatpak or snap packages - these are modern app packaging formats developed by RedHat and Canonical respectively with the goal to simplify the management of app's dependencies.
Using the generic approach using shared libraries - with this approach you'd need to package your app as an archive containing a directory containing you app and all its dependencies in the form of shared libraries - something similar to the approach of deployment on Windows where you put the dlls alongside the app.
I would recommend trying an AppImage first and then creating native packages for target distros.
Related
I'm developing a closed source application and to do so in accordance with the LGPL I have to dynamically link Qt's libraries to my application. Does Qt do this by default or do I have to take steps to do so? If that's the case how would I go about doing it?
Qt uses dynamic linking by default.
You'll notice this immediately during deployment to a non-developer machine, because your code will not run without the Qt libraries.
If your concern is the LGPL, just be careful when compiling Qt itself. Most LGPL violations with Qt are not because of static linking (since dynamic is the default), but for compiling Qt with non-default parameters.
LGPL is not just that the library must be provided along your binaries, but also that you specify how your users can build themselves the LGPL part. If you compile Qt yourself and do not use the pre-compiled binaries from the website, you must document that part of your build configuration in your release!
As soon as you get something running on your program, start preparing a release version for a non-developer environment without Qt installed. Your program should fail as soon as you delete the DLLs that you must copy along your program (or whatever format your OS uses).
It does it by default, statically linking seems to be quite involved judging by the many questions on the site regarding it.
I am using Qt in order to build a cross platform GUI app (Windows and Mac). I want to be able to update the app efficiently and automatically whenever there is a new patch available.
I saw this post which got me to take a look at WyBuild. It looks great and probably what I may end up using for the Windows version but what about Mac? What are some alternatives available to me?
I've just started developing a Qt-based autoupdater called Fervor for my own needs. You can try it out, contributions are more than welcome too.
For Mac the best choice is Sparkle used by WebKit, Adium, Cyberduck and more. Its only for Mac but I guess native look matters on Mac a lot.
Not familiar with WyBuild so cannot comment. Sparkle is a fine choice but the poster preferred a single app for both platforms. BitRock InstallBuilder contains an autoupdater written in Qt that can be used independently (disclaimer, I am the original BitRock developer). It is a commercial app, but we have free licenses for open source projects.
There is Updatenode which seems to provide a real Qt cross-platform solution.
It comes with a prebuilt client for Windows, Mac and Linux. The online service lets you manage updates very easy and are able to see good charts of your application usage.
And here another one of the possibilities:
Using the Qt Installer Framework: It provides installers for Windows/Linux/Mac with an build-in updater. If you need an example - The MaintenanceTool of your Qt-Installation uses the framework.
To get an auto-updater from it, all you need to do is:
Create an online installer (Just check the documentation, it's not that hard)
Use the maintenancetool in your application to check for updates.
This cane be done using my QtAutoUpdater. Go there for more information about the whole process
If new updates are available, the maintenancetool can be started in updater mode to install the update
Update the online repository - and your update is out.
Advantages:
Installer and updater in 1 tool - this means less work for you
Easy to use (with or without the QtAutoUpdater library)
Cross-Platform for all desktop platforms supported by Qt
The installer itself is a Qt original
Disadvantages:
No "native" installers (i.e. no .msi on windows or .deb on ubuntu)
Must be used together - if you want to use the update feature, you have to use the framework as installer
This may be obvious, but for Linux you can use the built in package manager. For example, apt-get, yum, pacman, or what have you.
I am looking for tips on how to package my Qt-based application for Ubuntu/Debian distributions. Let's say the application (executable) is myapp. Running objdump -p myapp | grep NEEDED, I see that it has the following dependencies:
libicuuc.so.44
libicui18n.so.44
libicudata.so.44
libQtGui.so.4
libQtCore.so.4
libpthread.so.0
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
I have gone through several online documents (listed at the end of this question), but am still fuzzy on where to install the actual files.
The Debian Filesystem Hierarchy Standard would suggest (I think) installing myapp in /usr/local/bin but I'm not sure about the ICU and Qt libs. It's important that the exact version of some of these libraries are used. (They have draft APIs which are being utilized that might break in future versions.)
I want to avoid "shared library hell" so that would incline me to place them in the application directory (/usr/local/bin), but the Debian Filesystem Heirarchy Standard would seem to discourage that.
I could place them in /usr/local/lib/myapp but then how do I ensure the correct version is linked dynamically? And if I do this, what do I have to do to add this directory to LD_LIBRARY_PATH on the target system?
As you can tell, I'm quite new to packaging for Ubuntu systems, so the direction I'm going may be completely wrong. I'm interesting in hearing from others who are doing this as to what they have found works best, particularly from a stability and ease-of-maintenance perspective.
Here are some of the docs I have gone through thus far:
Ubuntu Packaging Guide
Create Ubuntu deb-package from a Qt-application
Debian Filesystem Hierarchy Standard
Debian Policy Manual (on system)
Debian Developer's Reference (on system)
Debian New Maintainers' Guide (on system)
You need to look at the control section. You should not be distributing those shared libraries unless you are building them from source in your code. Those libraries belong to other packages that you need to list as Depends or Build-Depends for your package.
You say you are new to packaging on Ubuntu systems, what platforms have you packaged for? If it was only Windows, you are used to dll hell. It is much easier to avoid on Linux since you can say it requires certain libraries to be installed and the package installer knows how to find those libraries.
If you really want to make sure that your application uses the libraries that you ship it with, it probably makes sense to just do static linking of the license allows it. Since you are using a special, specific version of the libraries, you don't really want any other applications to use your libraries instead of the system libs supplied by the package management system. I've built static version of Qt before, and it's somewhat inconvenient, but not enormously moreso than building the usual dynamically linked version of Qt. I haven't worked with ICU, but I imagine it's no worse.
Failing that... Yeah, stuff it all in the application's directory, neatly away from the rest of the system. In my experience, most apps that do that sort of thing don't follow any official distribution standards for doing so, so users don't have very specific expectations in that regard.
Whats the best way to deploy a QT app? I've read the documentation hosted at trolltech but is it better to link with a static library or the dynamic libraries and have the user install the framework? I don't really want anyone using my app to have to download a 160mb framework just to run a simple gui frontend.
On OS X it's a good way to do a dynamic build and post-process the resulting ".app" with the macdeployqt tool which comes with Qt starting with 4.5.
This will copy the Qt frameworks used by your application into the application bundle, which results in a larger package than building a static version of your application.
Here is what you can do to make sure you get the smallest file size possibly in a dynamic build:
First off, make sure you only include the stuff you need (in the project.pro file's QT += core gui network xml lines).
Open the application bundle and remove any unneeded "Qt Plugins" from the bundle. macdeployqt automatically compies all the Qt plugins in there, which can be kind of bulky.
Make sure you are building your application in release mode. Otherwise your application might be linked against the debug libraries of the Qt4 framework, and they are really big (for instance, well over 90 MB for the debug library vs. 16 MB of a release variant without debugging symbols). This might be what happened in your case.
If you have a large application binary, you can use UPX to compress your executable file by 40-50%.
Other than that, you should use compressed disk images to deploy your application.
One of my projects uses QtGui, QtNetwork, QtCore and QtXml and the resulting bundle is about 16 MB in size.
Hope that helps.
Unfortunately you will have to include the Qt libraries you need into your own bundle, as you cannot expect your users to have Qt installed on Mac (whereas on Linux packaging systems allow you to require at least a given version of Qt.
There is a nice tool to help you with that, which is called macdeployqt. You just need to invoke it on your bundle application and it will pack the required libraries, changing the linkage of your binary to refer to them. Without it, making bundles for Mac is a real pain (it still is, but considerably less though).
http://doc.trolltech.com/4.6/deployment-mac.html#the-mac-deployment-tool
Afterwards, you can make a .dmg image as you would do with any other app. There is an option in macdeployqt that builds a basic one.
On Linux, it's better to rely on the OS's copy of Qt, as it's almost certainly installed - for OS X, almost all apps use a statically compiled library.
I have a windows screensaver that I want to recompile using the QT libraries, so that I can make available for more platforms.
I am facing problems with the deployment on Vista and XP.
I compile my screensaver statically with MT, and run the dependency checker.
The results are:
MyScreensaver.SCR needs several DLLS, QTCORE4.DLL but no MSVCx80.DLLs.
So far this is fine.
My problem is that QTCORE4.DLL in its turn, does need MSVCP80.DLL and MSVCR80.DLL
As a result my application does not run on Vista systems.
Can I build QTCORE4.DLL to be statically linked the the microsoft libraries (maybe Libcmt.lib ?) so that I do not have any dependencies in the MS CRT DLLs?
Limitations:
I do not want to have the users install the MS VC redistributables. The screensaver is only 1 MB, and it is ridiculus to ask the user to do so many changes in his computer just for a screensaver.
I do not want to use the trick to put the MS CRT dlls in the same application path with the screensaver because screensavers are installed in system32, and I want to install the minimum possible files there.
Finally, I do prefer to produce a monolithic program, rather that a bunch of DLLs
I tried a full static compilation and link of QT, but this is not allowed (if I understood correctly, by the LGPL) and also it is not recommended according to this: http://www.qtsoftware.com/developer/faqs/why-does-a-statically-built-qt-use-the-dynamic-visual-studio-runtime-libraries-do-i-need-to-deploy-those-with-my-application
After trying for solutions in various directions, it seems the most feasible one is to use the QTCore4.dll and QTGui4.dll, but having them linked statically to MSVCRT. In this way, neither my program, nor the QT DLLs will have dependencies on MSVCRT dlls.
Is there a solution to this?
( I am new to QT programming )
Thank you,
Michael
I think they are concerted that parts of your application will be compiled with /MD(d) and parts with /MT(d), but if you control everything (including 3rd party libraries) then its pretty safe to use /MT(d).
You have two options:
Those dependencies are part of Microsoft Visual C++ Runtime Library, you can deploy that library in your installshield and user silently installs it, MSVCRT library not included in Windows by default, you must deploy runtime library in your installshield and copy Qt*.dll DLLs in your application directory.
Use Static Linking of Runtime and Qt main dependencies, with this option you have one executable file, but to static compile of Qt you must have Qt commercial License for commercial use.