Do I Have to Include All These Qt Dlls with My Application

Do I have to include all these Qt dlls with my application?

UPDATE: Use windeployqt.exe! It works really well.

http://doc.qt.io/qt-5/windows-deployment.html#the-windows-deployment-tool

The simplest way to use windeployqt is to add the bin directory of
your Qt installation (e.g. ) to the PATH variable and then
run:

windeployqt <path-to-app-binary>

UPDATE: Upon Further testing, windeployqt did not copy over all the MingW dlls for me. (Tested with Qt 5.4 on Windows 10 with MingW 4.9.1). So you need to manually get the last 3 dlls before deploying:

libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll

From

C:\Qt\5.4\mingw491_32\bin

---

I think you may have a few extras in your list... I would double check the docs in the links below...

Here is the definitive documentation on it:

http://doc.qt.io/qt-5/windows-deployment.html

http://doc.qt.io/qt-5/windows-deployment.html#application-dependencies

Size of Qt DLLs

The amazing Qt Libraries can do a lot, but they are kind of big. Some of the older versions of Qt might be a little smaller.

For Qt 4.8 msvc QtCore4.dll is 2.5 MB, and QtGui4.dll is 8.4 MB.

How Windows Resolves Shared Libraries/Dynamic Link Libraries (DLL)

Here is how Windows tracks down a library at runtime:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

Single Small EXE

If you statically link, then your EXE should grab the libraries it needs and gets built into a stand alone exe. It still may be dependent on msvc redistributables. See the next section for more info on it. But it now compiles down the .libs that you reference into your EXE and your exe no longer is pointing at other dynamically linked libraries. It does take more time to get your statically linked exe environment setup.

Your exe will certainly get bigger as it now includes the binary information for the libraries that you referenced before.

https://www.google.com/search?q=qt+static+linking

EDIT:
Statically building the exe, means that you aren't using the LGPL version.
means that you have to have your object files easy to access to end users if you are using LGPL.

I think @peppe described it well (see comment below):

Technically, you are allowed to statically link when using Qt under LGPL, even if your application is not using LGPL. The only tricky requirement is keeping the ability for a third party to relink your application against a different Qt version. But you can comply with that easily, f.i. by providing a huge object file (.o) of your application, that only needs to be linked against any Qt version.

http://blog.qt.io/blog/2009/11/30/qt-making-the-right-licensing-decision/

Look at the chart near the bottom. If you are doing the commercial version, then you can statically link, without worrying about the object files.

MSVC Redistributables

Redistributable dependencies have to do with the run-time library linker options.

http://msdn.microsoft.com/en-us/library/aa278396(v=vs.60).aspx

/MD, /ML, /MT, /LD (Use Run-Time Library)

To find these options in the development environment, click Settings on the Project menu. Then click the C/C++ tab, and click Code Generation in the Category box. See the Use Run-Time Library drop-down box.

These two links below talk about some older versions of visual studio, but the reasoning should still stand.

http://www.davidlenihan.com/2008/01/choosing_the_correct_cc_runtim.html

How do I make a fully statically linked .exe with Visual Studio Express 2005?

Hope that helps.

Why Qt is making developers to include their dlls for every application?

I noticed that deployed on windows Qt applications are always including the dlls they needed.

This is called "local deployment".

Why did they made it that way?

I can think of a few reasons.

1. To avoid DLL Hell.
2. It is sanctioned by Microsoft. They wrote, "You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share." (see https://learn.microsoft.com/en-us/cpp/windows/choosing-a-deployment-method?view=vs-2019)

You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5)

Qt is a C++ library. C++ DLLs can differ by more than just a major version number. The DLLs could be built with MinGW, or they could be built with MSVC; They could be 32-bit, or they could be 64-bit. The different variants are incompatible with each other.

Example: if you force a PC to have one global copy of Qt 5.14.1 MSVC 32-bit and put that in your PATH, then:

• Other Qt apps on that PC that are built with MinGW cannot run.
• Other Qt apps on that PC that are 64-bit cannot run.
• Apps that must use Qt 5.13 might be broken. (For example, if a critical bug exists in Qt 5.14)

Why can't they do it like on linux? .... on linux these same applications use only "one" Qt library.

I listed a few disadvantages of this approach above. In addition, the version of Qt in Linux distros are usually a few versions behind so applications in the distro repository cannot make use the latest features, bugfixes, or improvements.

That's part of the reason why systems like AppImage and Snapcraft were invented. Sometimes, Linux users also want an app to contain a copy of its libraries, instead of having a single global copy of the libraries.

Is there a way to minimize Qt required Dlls?

You might want to do your own Qt build and cut it down as much as possible. It will still be a mess, but a smaller one. Remove optional modules you don't need, resort to using system libraries instead of those bundled with Qt wherever possible, don't use ICU - that alone will cut almost 30MB of dependencies.

The best option is to use a static build and link statically, but there are plenty of limitations at play, you either need a commercial license or to open your code, and still, deployment for QML projects is and has been broken for years. Sadly, it seems like making the lives of all of those using Qt for free as miserable as possible has become quite a priority, in order to force developers into spending on the expensive commercial license, which is the sole remedy to the situation, or at least it will be hopefully by the time Qt 5.7 is released.

BTW, if those DLLs got pulled in by the deployment tool - I advice against trusting it. I have tried it literally yesterday, and it turned out to be completely broken - failed to pull in half of the needed DLLs, half of those it pulled in weren't actually needed, and in terms of qml files, it did even worse.

If not by the deployment tool, those extra dlls are probably indirect dependencies - for example the web sockets define a QML API, so they might pull QML in as a dependency, which itself pulls a cascade of other modules and libraries. You should investigate if you can build those modules without their QML side.

Qt - Using 3rd party DLLs in my application

Maybe you need to link .lib statically, deploy dll with your program, include function prototypes and just use functions?
Static .libs are often provided so you don't have to do "dirty" work - they load dynamic library and export functions for you. For example Qt is usually used this way.

How to organize Qt DLLs with Qt-based dependency

You shouldn't be having any issues. Qt maintains binary compatibility over minor and patch releases (see http://qt-project.org/wiki/Qt-Version-Compatibility) and an application/DLL built with 4.6.x will run fine when bound to 4.8.x runtime.

• Your MyDLL.dll built with 4.6.0 will run with 4.8.5 runtime DLLs.
• Your application built with 4.8.5 will run with 4.8.5 runtime DLLs.
• Your application will run fine with MyDLL.dll as long as you are using the same interface you've always been using.

If you are seeing issues it is because of something else, and you will need to clarify exactly what problem you are having.

If you are not seeing issues and are just asking preemptively, then 1) just proceed as normal with no special considerations, and 2) you should have tried it first!

Building a Qt executable in Visual Studio 2017

To make your application ready for deployment, you can use windeployqt.
It is a commandline program that comes with Qt and collects all the required dependencies of your executable. Go to your QTDIR/bin/ folder and run this command

windeployqt <path-to-app-binary.exe>

It will scan your binary and copy everything that is needed next to it. For further details, have a look at the documentation.

---

Related Topics