Can't trouble running an executable file for my Qt Application

Robert Lech

Here's some background. I'm received a project that was created in Qt 4.x that I've migrated over to Qt 5.x; this means that I (with some help) fixed all the bugs in the source code so that it now compiles in Qt 5.x framework. Furthermore, I've added some features. Now, I'm ready to create a build so that I can show my research teammates (btw: here's a link to my build information . The problem is: I can't get the .exe file to run. Attempting to gives me an error saying:

The program can't start because Qt5Core.dll is missing from your computer. Try reinstalling the program to fix this problem.

I figure I'll solve this by tossing the Qt5Core.dll from the Qt install folder into my project folder. Running the .exe give me the same message, but this time asking for: icuin53.dll. Adding that file and running the .exe gives me the same error, except asking for icuuc53.dll. Adding that file and running the .exe gives me the same error, except asking for icudt53.dll. Adding that file and running the .exe gives me a different error: The procedure entry point _ZN10QArrayData10deallocateEPS_jj could not be located in the dynamic link library Qt5Core.dll. That one I don't know ho

list itemw to fix. Time for Plan B.

Plan B involves tossing the Qt5Core.dll from the mingw491 folder into my project folder. Running the .exe give me the same message, but this time asking for: libwinpthread-1.dll. Adding that file and running the .exe gives me a different error: saying: The procedure entry point __cx_throw_bad_array_new_length could not be located in the dynamic link library libstdc++-6.dll. Double stuck.

Here's some information on the build:
Build Directory: C:\Users\Robert Desktop\Code\Hofstadter\build-Hofstadter-Desktop_Qt_5_4_1_MinGW_32bit-Release
Effective qmake call: qmake.exe "C:\Users\Robert Desktop\Code\Hofstadter\Code\Hofstadter.pro" -r -spec win32-g++

Anything anyone can recommend would be super helpful since I'm not much of a "behind-the-scenes" programmer (I never got the experience to handle builds and stuff). Also, if this under the wrong category, please tell me and I'll move it.

EDIT:

@koahnig Thank you very much for your help. Your link explained some concepts to me. I had the "The procedure entry point _ZN10QArrayData10deallocateEPS_jj could not be located in the dynamic link library Qt5Core.dll." error message and wasn't sure how to deal with it. I realized I was using only .dll files from the C:\Qt\Tools\QtCreator\bin directory. When I used the .dll files from the C:\Qt\5.4\mingw491_32\bin directory -- including libstdc++6.dll which i should have just tossed into my build folder, my issues disappeared. This makes sense since I was using that MinGW instance to do my compiling. This forum question helped my problem more specifically.

Dependency Walker is still stating that I'm missing these files:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL

These are .dll files which some forums tell me are only side problems of something unrelated.

koahnig

Hi and welcome to devnet

When copying an executable to another machine you need to have also all required dlls. Please check the windows deployment guidelines.

You have started correctly by copying the Qt dlls to the folder with the executable. Howver, you need some more. libwinpthread-1.dll and libstdc++6.dll are dlls required by the compiler you are using.

You should use depends for checking additional dependencies. You have to be also aware of the platform plugins as listed in the link above.

The dependcy walker (depends.exe) can be downloaded.

harveyab

I have a similar situation. I am on Linux mint (two machines). I develop and build on one computer, and all is good. I put the executable file on the other and get similar errors.

Is it possible/feasible to build so that EVERYTHING is in one file? I want to build utilities that do not require "installation". Simply copy the executable file and it works.

How?

SGaist

Hi,

@harveyab the only solution is a static build, but you'll have to follow the licensing constraints that comes with it.

harveyab

@SGaist Can I try it on my own systems before I buy? What Qt package do I need to do static build? I have only "community" (free) so far. Will it do it?

SGaist

There's no pre-built static package, you have to compile it yourself. For your own use, there's no problem.

alex_malyu

Proper static build depending on Qt version is more challenging than provide dependencies.
I would advice against it especially for your case.

JKSH

@harveyab said:

Can I try it on my own systems before I buy?

Depending on what kind of license you want, you may not need to buy anything.

For example, you can continue using the Community (free) version if you follow the terms of the LGPL.

harveyab

Thanks all for your responses. I have some basic understanding of the Windows dlls but does Linux have an equivalent?

What are the options in Linux if I don't do a static build that gets everything into one executable file? And if I do a static build, will a bunch of stuff get included that is not actually used or needed in the particular program? Is the static build a build of the Qt packages that then gets linked in to and becomes part of any program I link with it, or is it that I do a static link of whatever program so it gets linked with only what it needs?

Please explain (or direct me to a clear description.)

harveyab

@alex_malyu Why do you say that; "advise against it". Ultimately I would want an all in one file if I ever release the program(s) to the public. And for testing purposes, I have my second Linux computer that does not have Qt installed, which I would like to keep that way from the start, so that I would know that any program I test on it really has no external dependencies. If the executable file becomes quite large because of a static build (which I expect it would), would that really be worse than installing a bunch of other files all over the place for anyone who wants to use my program? Dlls would have been a better idea if there weren't so many ways that your system can break when installs and uninstalls fail leaving an ever increasing state of chaos (especially in MS Windows).

kroman

@harveyab said:

If the executable file becomes quite large because of a static build (which I expect it would), would that really be worse than installing a bunch of other files all over the place for anyone who wants to use my program? Dlls would have been a better idea if there weren't so many ways that your system can break when installs and uninstalls fail leaving an ever increasing state of chaos (especially in MS Windows).

You can put all necessary dlls into one single directory (where exe-file lives), so your Qt-based program will work with no external dependency (outside your program directory) at all.
For easy distribution you can bundle all files into one single zip-archive or create installation file using NSIS or InnoSetup (they are free).
Written above is true for Linux too. There are so-files (brothers of Windows dlls) and ldd command line utility - depends.exe analogue on Windows.

JKSH

@harveyab said:

I have some basic understanding of the Windows dlls but does Linux have an equivalent?

Shared libraries are called DLLs ("Dynamic Link Libraries") in Windows, and SOs ("Shared Objects") in Linux. They are essentially the same. For example, if your program requires Qt5Core.dll and Qt5Gui.dll to run in Windows, a Linux build of your program requires Qt5Core.so and Qt5Gui.so.

What are the options in Linux if I don't do a static build that gets everything into one executable file?

Same as Windows: Provide the required shared libraries with your executable.

Alternatively, you could install the libraries to a system-wide location, but that's often not recommended.

And if I do a static build, will a bunch of stuff get included that is not actually used or needed in the particular program?

I'm not entirely sure as I usually don't use static linking, but I think only the libraries you need get embedded into your executable.

Is the static build a build of the Qt packages that then gets linked in to and becomes part of any program I link with it, or is it that I do a static link of whatever program so it gets linked with only what it needs?

There's a nice diagram at http://stackoverflow.com/questions/311882/what-do-statically-linked-and-dynamically-linked-mean (replace "crtlib" with Qt libraries)

See also http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking

@alex_malyu Why do you say that; "advise against it".

I'm guessing it's because it's very a lengthy process that's not strictly necessary. If you're willing to take the time to learn it, then there's no problem (aside from the time involved)

Ultimately I would want an all in one file if I ever release the program(s) to the public.

If you want only 1 binary file at the end of the process, then you need to take the static linking route.

Just be aware of licensing implications. This is a currently a legal grey area, but the commonly accepted wisdom says that if you statically-link your program to the Community edition of Qt, then your program must be released under the GPL/LGPL. You have fewer restrictions with dynamic linking.

And for testing purposes, I have my second Linux computer that does not have Qt installed, which I would like to keep that way from the start, so that I would know that any program I test on it really has no external dependencies.

I test deployments on my dev machine by temporarily moving my Qt dev folder away from its usual location. That makes it unfindable, so programs on my system think I don't have Qt installed.

If the executable file becomes quite large because of a static build (which I expect it would), would that really be worse than installing a bunch of other files all over the place for anyone who wants to use my program? Dlls would have been a better idea if there weren't so many ways that your system can break when installs and uninstalls fail leaving an ever increasing state of chaos (especially in MS Windows).

It sounds like there are only 2 options in your mind:

Produce one large statically-linked executable
Produce one small dynamically-linked executable, and have your users install Qt libraries in a system-wide location that everyone has access to.

In reality, developers use a 3rd option nowadays:

Produce one small dynamically-linked executable, and include local copies of the dependencies with your app installer. No chaos -- these DLLs/SOs are exclusively for this app only, and not accessible to other apps.

This means there's no significant difference in total file size of your distribution, whether you go with static or dynamic linking. With Qt 5.4, the benefits of dynamic linking are: (1a) licensing flexibility, and (1b) no need to compile Qt yourself. The benefit of static linking is: (2) No need to think about which libraries to deploy.

SGaist

To add to @JKSH, static libraries can link to shared libraries. e.g. On Windows even if you build Qt statically by default it's linked to the dynamic runtime of MSVC. In any case, static linking should only pull in what your software uses (and its own dependencies)

harveyab

Thank you all for your good answers. Now I have a better understanding and some options that sound not so bad as I thought.

Robert Lech

@koahnig Thank you very much for your help. Your link explained some concepts to me. I had the "The procedure entry point _ZN10QArrayData10deallocateEPS_jj could not be located in the dynamic link library Qt5Core.dll." error message and wasn't sure how to deal with it. I realized I was using only .dll files from the C:\Qt\Tools\QtCreator\bin directory. When I used the .dll files from the C:\Qt\5.4\mingw491_32\bin directory -- including libstdc++6.dll which i should have just tossed into my build folder, my issues disappeared. This makes sense since I was using that MinGW instance to do my compiling. This forum question helped my problem more specifically.

Dependency Walker is still stating that I'm missing these files:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL

These are .dll files which some forums tell me are only side problems of something unrelated.