[Moved] day one: failure...
-
You've just run into what is generally called "DLL hell":http://en.wikipedia.org/wiki/Dll_hell. Nothing specific to Qt here. Everyone who deploys programs on windows has this same problem. There is no really easy way to get around this. For your own system, you might consider adding the Qt bin directory to your PATH, as well as the mingw bin directory if you use that compiler. For other systems you will have to know exactly which DLLs are required for your program (usually QtCore4.dll and QtGui4.dll are required, as well as some specific dlls for modules (e.g. QtOpenGL4.dll, QtWhateverModule4.dll). Then you need some mingw dll as well. All of those have to be of the correct version of course. It could help if you were a bit more specific on what entry point errors you got, so we may provide hints on what dll to add.
If I recall correctly, you can use the Qt command line environment for quick testing, but the system PATH would be more convenient in the long run.
-
It sounds as if Windows is not finding the right dll's when you try to run the app from windows explorer. This much you have guessed ;-)
The reason that you may have two sets of Qt dll's with different sizes is that:
- Qt Creator itself is built against the MSVC runtime since that leads to slightly better machine code.
- If you chose to download and install the MinGW compiler and environment then you will have another set of Qt dll's built with MinGW that your applications will need in order to run. This is offered because not everybody can afford to pay MS for a copy of MSVC.
I would guess that Windows is simply not able to find the MinGW compiled Qt dll's due to lack of the appropriate directory in the %PATH% environment variable. WIndows uses this list of dirs to look for dll's when you launch an app.
I am not in windows at the moment so I cannot check the exact path you need to add to %PATH% but look in your Qt SDK installation directory and see.
Am I right about you using the MinGW compiler in the SDK first though?
-
Having developed an application using Qt in a Unix environment (Linux and OS X) and then gone through the pain of building it in a MS/Windows environment I can certainly sympathize with the frustration expressed by the poster. The note in the reply about "DLL Hell" is very apropos (more below about the solution we implemented). I also note that a no charge version of the MSVC compiler is available that seems to be the best way to go unless one needs the full development environment.
For our application, in addition to the Qt libraries we needed to port additional library dependencies including a proprietary engine needed by our application. Since the application was coming from a Unix environment we considered using Cygwin. But while Cygwin helped immensely in providing a Unix-like operating environment (various utilities including GNU make), the libraries built by its gcc compiler did not get along well with other libraries. We also tried MinGW but had problems with it correctly building our libraries. So our solution, after much trial and error, was to use the MSVC compiler across the board. With some finagling we were able to incorporate MSVC awareness into the Makefiles (using GNU make syntax) that we use for building the software on all platforms. The Qt qmake utility will generate the appropriate Makefile, of course, but it requires the use of nmake (which, I believe, is included with the Microsoft installation) rather than gmake.
The pit of DLL Hell was avoided by building everything statically, including the Qt framework (required system libraries expected, of course). Some searching revealed that this is the recommended solution by those familiar with the problem. Yes, this results in a larger executable file, but it consistently works on all versions of Windows on which we have tested it: we build on a 32-bit XP system and the executable runs successfully - without any library hassles - on Vista and Windows 7 including 64-bit OS.
The bottom line recommendation: Use the MSVC compiler and build everything statically.
-
Thank you all very much for your kind replies and guidance. I have taken several deep breaths and unclenched my fists. I have grown too comfortable and perhaps a little lazy. So, getting this all set up to function as I think it should will be good exercise for me. I see from your replies that others have passed this way. Day two will be better because of your help. I sincerely appreciate your assistance.
-
[quote author="Castalia" date="1304728833"]With some finagling we were able to incorporate MSVC awareness into the Makefiles (using GNU make syntax) that we use for building the software on all platforms. The Qt qmake utility will generate the appropriate Makefile, of course, but it requires the use of nmake (which, I believe, is included with the Microsoft installation) rather than gmake.
[/quote]That is incorrect. In fact Qt-Creator ships with jom.exe which is a clone of nmake but also allows multiple parallel build jobs to better utilise modern multi-core processors just like GNU make does via the -j option.
Qmake will generate makefiles that make use of whatever toolchain you tell it to use via the mkspec files - either a shipped one or a custom hand-made one.
There really is no need to build everything statically as this can bring it's own headaches. All that is required on the dev machine is to have a suitable %PATH% configured. Hen it comes time to deploy to other machines use a tool like depends.exe to find which dll's are needed and ship those along with your app in an installer. I can recommend the NSIS installer which is free.
-
I wanted to let everyone know how grateful I am for all of the expert assistance and also to let you know that I have now been able to run the "declarative" sample (Toys\Clocks)...sort of...but I don't care, because the example programs from the QT C++ Examples section of the Welcome page run perfectly outside of the environment. That is all that I needed. The QT Quick examples all display a container window and that is all. No errors, just an empty window, but as I said, I don't care. I am doing something obviously stupid with those examples and so I will read the documentation now, and surf and become familiar with the product and then return to the QT Quick samples some day. For now, I am totally pleased to have the "regular" C++ AudioDevices and the CollidingMice samples working as expected (both modified enough to ensure that I am not just hallucinating). Thanks again to all of you.
-
Welcome aboard, Errol!
I hope you get your DLL hell sorted out. If you have an idea how we can help with this from Qt Creator, please feel free to post a suggestion into "our bugtracker":http://bugreports.qt.nokia.com/. We are always looking for input from newbies (and anybody else with good ideas of course:). The whole dev team working on Qt Creator uses it for their daily work (and I think that does show), but since all of us are rather deep into the Qt ecosystem we sometimes do miss the issues a newbie faces... after all they are perfectly obvious after dealing with them for a couple of years! :)
I hope you will enjoy your Qt-project (after getting over the initial frustration).
-
Tobias, not sure if it makes sense but when using the MinGW toolchain it might be an idea for the SDK to add the necessary lib dirs to the %PATH% environment variable. Would that screw up other stuff (e.g. creator) if the runtime linker finds the MinGW compiled Qt libs first or is it sensible enough to skip over the incomaptible dll's and keep looking elsewhere?