[Solved] Windows: deployment failure on non-development machine
-
Qt Version: 5.1.1, Windows online download (seems to include all variants: mingw, vs2010, vs2012, 32/64, etc).
Windows 7 (all updates applied)
Machines:- development: iMac with Windows 7 on bootcamp
- non-dev : MacBook Pro Retina, Windows 7 on bootcamp
IDE: Qt Creator, building with vs2010, 32-bit, debug version
Project: licensewizard, from the provided Qt examples
I can build/run this from Qt Creator successfully.
I created a "deployment folder", and copied the exe, manifest file, and necessary Qt DLLs. The exe in this folder runs correctly on my development machine (as one might expect).
I copied this deployment folder to my non-development machine, and on trying to run it I got errors for missing DLLs: MSVCP100D.Dll and MSVCR100D.DLL. Grabbed copies of these from the dev machine, and added to the deployment folder. Now I get the infamous "The application was unable to start correctly (0xc000007b)".
Searching this forum and the web found suggestions to use the Dependency Walker. Running that on the (working) dev machine, I get several "The system cannot find the file specified" (for API-MS-WIN-*, dcomp.dll, gpsvc.dll and ieshims.dll). Neither dcomp.dll nor ieshims.dll can be found on either machine. But again, the exe runs on the dev machine and not the non-dev machine.
Running the Dependency Walker on the version on the non-development machine shows the same "missing" libs, but strangely also tags MSVCP100D.Dll and MSVCR100D.DLL as "x64" (they're tagged as "x86" when I run the walker on the exe residing on the development machine). Not sure if this is just a red herring (some oddness in the dependency walker?), or what, though... As well, if I copy gpcvc.dll to the non-dev machine's deployment folder, it gets tagged as "x64" by the Dependency Walker...
In any case, I've read everything I can find online that mentions Qt and error 0xc000007b, and have not found a solution to my problem. I've got a fresh out-of-the-box vanilla Qt version, using Qt example code/project, and I'm basically stuck...I'd like to be able to create a 32-bit Qt app, using a 64-bit machine/OS, and it's not working on the very first non-dev machine I'm trying it on.
Any help/suggestions would be most welcome. Should I start over - wipe Qt 5.1.1 and just download the Windows 32-bit Qt for vs2010? Is there some non-obvious setting I should change? Something path-related (but remember that non-dev machine is extremely vanilla and uncustomized)? Anything to try out that "just might help" :-) ?
I'm not a terribly proficient Windows person (lots more Linux and Mac), so don't assume a lot of expertise on my part...
-
Update:
I went through the same process, this time for a Release build instead of a Debug build. This time, it runs (!)
Are there other files I should include as part of the deployment, which are created by a debug build? Or is a "debug deployment" just not supposed to work on Windows?
-
Re. "debug deployment" this works like a charm on Linux systems because the .DLLs usually, and also in Qt, they have the same name, regardless if they are from a release or a debug build.
But on Macs debug builds filenames are suffixed with "_debug" and on Windows they have at "D" suffix. So on these systems "debug deployment" are much trickier.
On Macs you can override the .dll selection with otool but on Windows I usually just copy all the *D.dlls I think are needed together with the app.exe file.
So to avoid 0xc000007b you need to copy a lot of *D files :-) You can use Process Explorer from System Internals on your dev machine to see them...
-
Yeah, my guess is that there are some require files (dlls almost certainly) that aren't being found, and unfortunately are not triggering any explicit "complaints" from the runtime about their being missing-in-action. I'll see if I can uncover anything more with the Process Explorer...thanks for the suggestion.
I'm actually just more curious/annoyed about this...don't really need a debug deployment all that much...just might be occasionally convenient...
-
BTW, another approach is to use static linking, i.e minimize # of .dlls the runtime needs, haven't tried that so much with Qt (always do it with my legacy MFC-apps in Visual Studio).
For example, Qt install app you download is statically linked, so it only needs something like 10 .dlls from Windows itself.
-
Hi,
Did you follow the "Windows deployment guide":http://qt-project.org/doc/qt-5.0/qtdoc/deployment-windows.html ? It contains the informations you need to get a Qt application running on other computers.
Also note that static builds implies some licensing issues
-
IIRC, the debug runtime from Microsoft is not redistributable.
