So I have Visual Studio 2013 (community edition) with Qt addin installed, Qt5 libraries (32bit), and I'm trying to create an executable that is independent of all development configurations (it may use static or shared libs, I don't really care at this point).
OS: Windows 7, x64.
For doing this I changed the Solution Confguration visual studio option from Debug to Release, and add all the necessary libs in Configuration Properties -> Linker -> Input -> Additional Dependencies. The application now starts only if I run it from visual IDE, If I try to start it from the generated .exe I got The application was unable to start correctly (0xc000007b) error.
I have searched and found that this error code indicates one of the following problems:
32-bit app tries to load a 64-bit DLL (not my case I think, Qt DLLs are 32bit (I have installed using this .exe: qt-opensource-windows-x86-msvc2013-5.5.0.), and I use some other .DLLs which are also 32bit).
There are some missing DLLs. (I did copy all the necessary Qt DLLs in the same folder with the final executable).
For checking what dependencies my app requires, I opened the .exe file with Dependency Walker application, this is what it shows me:
in this list were also Qt5Multimedia.dll and Qt5SerialPort.dll, I get rid of the errors by copying the .DLLs in the same folder with the .exe.
Any ideas how to solve this?
You should never do that operation manually unless the standard procedure completely fails. There is already standard tool for Qt Windows deploymend windeployqt.
It takes care about Qt DLL dependencies, makes a copy of platforms\qwindows.dll and also it makes a copy of libraries that you cannot detect with the Dependency Walker, since image plugins and some other are loaded at runtime.
You do not even need to have your Qt bin folder in your environment PATH. The simplest deployment:
copy built exe binary to a new folder
open cmd console in that folder
call windeployqt using its full path (if it is not in the system PATH) and provide your executable, for example:
c:\Qt\Qt5.5.1-vs2013-x64\5.5\msvc2013_64\bin\windeployqt.exe application.exe
As a result you have in that folder all needed Qt DLLs. Of course you can have also issues with MSVC redistributables, but those should be deployed separately and installed once per system.
The tool windeployqt has various options. It can also take care about deployment of qml related files.
Only some 3rd party libraries should be copied manually if they are used, for example OpenSSL.
Solution:
As I got deeper, I have found this answer, after doing what that answer indicates (I actually copied all the .DLLs located in \Qt5.5.0\5.5\msvc2013\bin to the folder where my .exe is located), the error message changed from The application was unable to start correctly (0xc000007b) to Application failed to start because it could not find or load the QT platform plugin “windows”.
Searching on web for more about this error, I have found from this answer that you also need the platforms folder in the same location with the .exe (which was located in Qt5.5.0\5.5\msvc2013\plugins path). After copying that folder, the application started without any problems!!!
Now I just need to delete all unnecessary .DLLs from my application folder (Dependency Walker does not offer very useful information about this), and all the deployment is done.
I have solved the problem in the same time as describing it, so I guess I will just leave this here, may help others that have the same problem.
Related
After switch to release mode to build a small project I have, when I try run it from inside the qt-creator ide, all goes fine. But when I go to the folder build-<project_name>-Desktop_Qt_5_14_1_MinGW_64_bit- Release and try run the executable generated in this directory, I got this error:
Anyone knows what the problem here? If it was some missing dll, I supose it will specify what dll was missing, right? Or I am mistaken?
update
After run windeployqt, this command found dependencies for my application, create some folders, but now I am getting tis error when try to run it:
update 2
after run the utilitary dependency walker, i got this errors on it:
I am using this build kit to build the project in qt-creator:
Here is all I know about Qt deployment & issues on Windows.
Check whether Release configuration of your project doesn't contain links to any debug versions of libraries.
Build your app in Release mode. Use Rebuild, If in doubt. See compile output window in the IDE, what paths it actually uses.
Use windeployqt tool to automatically copy all the necessary Qt dlls to the executable's folder. Be sure you are using windeployqt.exe from the correct folder. For example, currently I have one version of Qt framework, but two versions of windeployqt: for x86 and x64 compilers. In the case you have more than one version of Qt installed, you may have several versions of the tool.
.
C:\Qt\Qt5.14.1\5.14.1\msvc2017\bin\windeployqt.exe
C:\Qt\Qt5.14.1\5.14.1\msvc2017_64\bin\windeployqt.exe
Copy compiler libraries to the release folder. Make sure that you're copying libraries from the exact compiler you used to build.
Copy all necessary additional 3-rd party dynamic libraries. Make sure it is not debug versions.
If the problem persists, press Ctrl+C when the error message is active. It will copy all the text from the message box. Paste main part of the message to Google.
If the problem persists, open your .exe file in some dll-dependency viewer. Here is how I can see this in Lister. Be note that such a tool will show you not only missing dlls, but also a full path for each dll that your executable actually use. More power tool is Dependency Walker.
Make sure your application doesn't try to write something to a system protected folder, such as c:\Program Files\, without corresponding privileges.
If the problem still persists, simplify your project as much as possible. Run Release for an empty project. Than add modules, functionality and libraries step-by-step.
If everything is okay, test the application on a completely clean virtual machine.
Edit. I google your error text and what I found:
https://stackoverflow.com/a/52127944/
The problem was that windeployqt was unable to locate gcc for some
reason. I added it to my path from cmd with SET
PATH=%PATH%;C:\Qt\Tools\mingw530_32\bin. After I ran windeployqt
again, I did not have to copy libgcc_s_dw2-1.dll and
libwinpthread-1.dll over manually and it used the correct Qt5Core.dll,
since the application is now working fine.
I've been googling for a solution to this issue and although I've found many people sharing my problem none of their solutions work for me.
I wrote a C++ application using Qt framework using Visual Studio 2010. I built and ran the application in "Release" mode from Visual Studio without issue, but when I copy that exe from the Release folder to a new destination (pretend its a new PC) it fails to run providing this error:
---------------------------
TestApplication
---------------------------
This application failed to start because it could not find or load the Qt platform plugin "windows".
Available platform plugins are: windows.
Reinstalling the application may fix this problem.
Within the executable directory I have the following file structure:
./TestApplication.exe
./libGLESv2.dll
./Qt5Core.dll
./Qt5Gui.dll
./QtWidgets.dll
./platforms/qwindows.dll
./qt.conf
All dll files were taken from the 5.0.0 build of Qt in the Qtbase folder where the libraries reside.
The qt.conf file is:
[Paths]
Plugins=.
Without it, the launch error is the same except it says "minimal" and "offscreen" are available platforms as well.
For all other people experiencing this error it seemed to be solved by creating the platforms folder and putting in the qwindows.dll. But doing that myself doesn't change any behavior.
Is there something I've done wrong? Perhaps my method of generating the .exe in the first place is wrong?
If you are using libGLESv2.dll, then you must include libEGL.dll, too.
You can't see that in depends.exe, don't know how the Qt developers managed to hide this.
If your Qt is out of the box, then both Dlls are necessary even if you are not using OpenGL.
Also, if your Qt is out of the box, you need to include also the three ic*.dll, which contain information for Unicode handling.
You can see which DLLs are needed by looking at which ones are invoked when running Debug (F5) in Qt Creator.
=Carl
The release is likely missing a library/plugin or the library is in the wrong directory and or from the wrong directory.
Qt intended answer: Use windeployqt.
Qt comes with platform console applications that will add all dependencies (including ones like qwindows.dll and libEGL.dll) into the folder of your deployed executable. This is the intended way to deploy your application, so you do not miss any libraries (which is the main issue with all of these answers). The application for windows is called windeployqt. There is likely a deployment console app for each OS.
I'm getting started with Qt and have encountered the following issue: when i compile and run my application from within QtCreator it runs all right, but when i go to the debug folder and double click .exe file to launch the app a message box pops up and it says
This application has failed to start because QtDeclaratived4.dll was not found. Re-installing the application may fix this problem
Please notice - it is QtDeclaratived4.dll with letter d before 4, not QtDeclarative4.dll.
After searching in Google i found an advice to find the needed dll and put it inside project folder. But unfortunately such .dll is missing on my computer. I found QtDeclarative4.dll and tried putting it inside project folder but it didn't help. Can you propose me any other solution?
The d in the name indicates the debug version of Qt, which means that you compiled your application using the debug build.
You probably have this DLL on your computer and Qt Creator knows where it is, that's why it is able to run your application. However, you don't have the path to this library configured in your PATH environment variable, that's you are not able to executable your application manually (i.e. outside Qt Creator).
To fix this issue, you have 2 choices:
Compile your application selecting the release build;
Or add the full path to QtDeclaratived4.dll to the PATH environment variable.
QtDeclarative4.dll can be found in C:\[QT_INSTALL_DIR]\bin
You should definitely have this if you used the standard Windows installer that Qt distrubutes.
Until now my Visual Studio 2008 debugger gracefully stepped into Qt library code when I pressed F11. After upgrading Qt to the latest version and changing QTDIR, F11 does not step into library code anymore. Any clues how to make the debugger smart again?
Activate the modules list, Debug - Windows - Modules, to see what libraries are loaded and if debug symbols are loaded for those libraries. Note that you need to have the debugger active on your process to be able to do this.
In debug mode, the Qt libraries should be suffixed by d. QtCored4.dll for instance. If you see QtCore4.dll on the list, you have linked to the wrong libraries. If it does say QtCored4.dll but under Symbol Status there is something different than Symbols loaded., then that's the reason. You can manually load the symbols here by right clicking on the dll and selecting Load Symbols. It asks for the Pdb file after clicking that.
You can add more pdb file locations, if they weren't loaded but exist, from Tools - Options - Debugging(tree) - Symbols(tree). If you want the symbols to be automatically loaded.
Should it give some error, that the pdb file doesn't match the binary or something like that, you should re-build your Qt debug version, unless you have more pdb files to try. Use the Visual studio command prompt and go to the Qt directory, run configure and nmake. It takes a while, possibly some hours. There was some switch to only build debug version but i forgot where it goes. Note that the build might fail and after that it's a lot of fun www.google.com searches. The best bet might be to get the source only package, I forgot where to get that and it's not easily found. If you know where to get it, tell me please. I vaguely remember that there might be some other way to build the debug version, but this is the only one i know for sure.
#0xbaadf00d's recommendation to "open the Debug/Windows/Modules view" for verifying which modules have loaded successfully and which are not loaded is extremely useful.
Here is a summary of what I check when I need to step into Qt source code:
The DLLs must be for the Qt version in developer's Qt kit
The Qt .pdb files must be present in Qt kit's folders: bin, lib, plugins/platforms, plugins/qmltooling
Visual Studio Tools/Option/Debugging/Symbols needs paths to .pdb files:
If qt.conf file is used, must point to correct bin folder
If target is WinCE or WEC2013 and using HKLM\Loader\SystemPath, you must specify path to DLLs in SystemPath variable
Set the location for the source files in the project property pages:
My app launches from inside Qt Creator no problem, but when I go into the debug folder, I
find the .exe file and I try to launch it, it complains that there is a missing DLL called mingwm10.dll.
I don't know how to fix this problem I tried the release as my build target, same thing happened.
Unless you compiled Qt statically and link to it statically, you will need to copy the Qt DLLs with your app when you go to deploy it to another computer, just copy the mingwm10.dll with them (it's in at least two places in my Qt install: <install path>\Qt\2010.02.1\mingw\bin and <install path>\Qt\2010.02.1\qt\bin).
For just running on your own machine, I would suggest you add the <install path>\Qt\2010.02.1\qt\bin path to your "Path" environment variable. This should allow your apps to run properly outside the IDE without having to copy the dll around for every project until you go to deploy it elsewhere.
I think, there are two ways to fix this. You can copy the mingwm10.dll from the MinGW directory to the directory of your exe file or you can recompile Qt without the dependency to mingwm10.dll (which seems to be used for thread safe exception handling). I found some information about it here: http://lists.trolltech.com/qt-interest/2006-08/thread00942-0.html