I’ve written about deploying a simple Qt app, but what about deploying a more complex, “real” Qt app. This means copying all the needed files: besides the main executable file there usually are some shared libraries, e.g. DLLs, and some other files like configuration or certificate files. In this blog post I’ll concentrate on getting the binary executable files setup correct; of course there can be other important files, like the
qmldir declaration file in the QtQuick.2 subdirectory etc. but that’s a topic for another blog post.
First there’s the option of static linking i.e. one build that packs all of Qt’s DLLs and your code together in a single .exe file. This hugely simplifies deployment, but it’s a time consuming process that can be tricky; of course if you distribute large quantities of your software, static linking is definitely something you should try.
But if you’re not yet targeting a couple of millions of PCs (or a similar number 🙂 ) then you’re building your Qt app the normal, dynamic way. And that app structure in Qt depends heavily on shared or dynamically loaded libraries; on your deployment PC the Qt installer sets these up for you, but on other PCs you need to do it yourself. You can either use an installer, for example Qt has a good one, or copy the files manually.
By now Windows XP is getting a bit long in the tooth and Microsoft has dropped support for it. Windows 2003, though, is still supported by Microsoft. If you’ve using Qt together with Visual Studio (and not the MinGW compiler) and you try deploying your app to a Windows XP or Windows Server 2003 computer, chances are you’re seeing this error:
This error will not occur for Qt with Visual Studio 2010, but it will when using Visual Studio 2012, 2013 or Visual Studio 2015.
Update thanks to comment below: (use QMAKE_LFLAGS_WINDOWS instead of tweaking the project’s setting): There are basically two ways to fix this; the easy way is to add one extra line to your project’s .pro file, or you can be more adventurous and binary-patch your app’s .exe file.
And yes, this has to be applied for every app you develop, until XP is gone gone gone…
Once you’ve built your first Qt program, have you tried it on another PC?
(Post updated and simplified! Thanks to JKSH on the Qt Project forums.)
Maybe you’ve gotten past .DLL errors and instead got errors like this?
(Want to skip the tourist talk? Jump to the rest of the post.)
If you look at newer languages like Google’s Go, you’ll find an Everything and the Kitchen Sink™-flavored approach to deployment. After you’ve written and debugged a Go program, you issue the
go build command. The result is an .EXE file with minimal dependencies on the DLLs, in Windows for example it’s just the usual suspects like KERNEL32.DLL etc. People sometimes complain though, because even a simple ‘Hello World’ app weighs in to an approx. 2MB .exe file. But deployment problems are more or less nonexistent.
Qt has (as you’ve probably discovered) the complete opposite design. From things like .h files that are designed this way (a humongous file like Windows.h is frowned upon) to the delegation of .DLLs that Qt uses for plugins, platform independency etc. Partially this stems from the early 90’s when Qt was initially designed (in those days, deploying a 2MB .exe could constitute a career-limiting move) but probably mostly because it supports so many different architectures and OS’es.
Now, to simplify deployment of Qt apps to other PCs, you can build your app together with Qt statically. For example, the MaintenanceTool app included in your Qt’s root directory is built that way (as well as Qt’s online/offline installer programs). In some environments that makes sense or is required (like when deplyoing Qt apps to iOS/iPhone) but let’s begin with the simple version: distributing Qt using DLLs/shared files.