So if Creator can't find the library in question then it won't be able to use your qmake. You need to make that library accessible from the "default" command prompt or start Creator with environment set so that it can find it.
So if Creator can't find the library in question then it won't be able to use your qmake. You need to make that library accessible from the "default" command prompt or start Creator with environment set so that it can find it.
My friend wysota, your suggestion seemed to work at first. I edited qtenv.bat from the binary installation, changing the value of the QTDIR variable and PATH variables, adding a line that automatically starts Qt Creator and saving the modified batch file elsewhere. Then, I started Qt Creator with this batch file and in the Version Management section of the Options dialog, it picked up the second Qt installation right from the PATH variable, it only needed to be told the path to MinGW.
Unfortunately, trying to build some of the projects inside the examples directory (.pro file edited to add a CONFIG += static line) , I had no luck with running the resulting executables. They always asked for some Qt dlls as dependencies. It's interesting though, that the dependency upon libgcc_s_dw2-1.dll, which is the first to come up in dynamically linked executables, was eliminated. Maybe it's because I ended up with a mixed build environment (Qt libs from one installation, GCC from another)? Right now, I'm starting from scratch for the second Qt installation dir, but this time with this download: ftp://ftp.qt.nokia.com/qt/source/qt-....6.1-mingw.exe and hoping for better results.
Seeing some screenshots here, I really wonder how these fellows did it. It's irksome, to say the least!
Open those examples in Dependency Walker to see what they depend on. Also inspect your Qt libraries to see if they are indeed statically built. Having multiple Qt installations be it shared or static is really not a problem.
For the Puzzle example (examples\draganddrop\puzzle), it's QtCore4.dll and QtGui4.dll.
How would I go about doing that?Also inspect your Qt libraries to see if they are indeed statically built.
Moreover, isn't configuring and building Qt according to these instructions the proper way to get static versions of the Qt libs? I would show you the configuration file I saved with configure's -saveconfig switch to verify my adherence to the letter to the instructions (I didn't forget to also edit the mkspecs\win32-g++\qmake.conf file), but it's gone now since I started over with the download I mentioned previously.
Did you distclean the directory and reran qmake before compiling them?
Output of dependency walker, size and extension of the library file are relevant.How would I go about doing that?
Yes, provided you did everything correctly. But as something doesn't work it is probable you didn't do everything correctly. We don't even know if you are having issues with Qt itself or with Qt Creator. You should build those examples from the commandline using the proper instance of qmake to be sure Qt is built as you wanted it.Moreover, isn't configuring and building Qt according to these instructions the proper way to get static versions of the Qt libs?
Relied on Qt Creator for this: Right clicked on the project entry and selected "Clean".
Ah, you mean using Dependency Walker to check the secondary Qt installation's libs themselves. I'll do it as soon as my workstation is done rebuilding Qt.Output of dependency walker, size and extension of the library file are relevant.
No other issues with Qt Creator whatsoever. Using the primary Qt installation, that is. But I believe you are right about the commandline: if it doesn't work from there, it's only natural that it can't be done from inside Qt Creator either.We don't even know if you are having issues with Qt itself or with Qt Creator. You should build those examples from the commandline using the proper instance of qmake to be sure Qt is built as you wanted it.
Thank you for your advices so far, I will get back with more information.
OK, back with more information. Decided to ditch the idea of using an installation from qt-win-opensource-4.6.1-mingw.exe and just repeat carefully the steps described in post #1. So, I extracted again the tarball with the Qt sources (this time, a minor change in the target directory name, where there was an underscore now there's a hyphen). Ran configure with these parameters:
Edited the \mkspecs\win32-g++\qmake.conf file, and built:Originally Posted by C:\Qt\2010.01-Static\configure_parsifal_static_qt.cache
Building completed with no errors. Next, for ease of use, the duplication of the SDK's "Qt Command Prompt" shortcut, along with a modified version of qtenv.bat normally found inside the SDK's \bin subdirectory:mingw32-make sub-src
From inside the modified command prompt's environment, I navigated to C:\Qt\2010.01-Static\examples\draganddrop\puzzle and entered:Originally Posted by C:\Qt\2010.01-Static\bin\myqtenv.bat
...to build the "puzzle" example. The executable produced inside the release subdirectory "weighted" around 7.5MB and ran with no errors. Dependency Walker showed no problems, apart from some dependencies which proved to be two standard Windows files (gpsvc.dll and ieshims.dll).qmake
mingw32-make
Next, I thought I'd use Dependency Walker to check the Qt libs themselves, as you suggested. But there were no DLL versions of the libraries to be found inside the secondary Qt installation's directory (such as those inside the \bin subdirectory of the SDK installation). Only the static .a versions inside \lib. And those are apparently not in the PE executable format that Dependency Walker recognizes, tried opening for example libQtCore.a and DW failed. Did you mean checking other files inside the static Qt's location?
Some more info, continuing from the situation I left in #11:
I tried again to make Qt Creator recognize the second Qt version/installation. No luck there, same result as the one in post's #1 screenshot.
Next, I started Qt Creator from the modified Command Prompt mentioned in my previous post and opened the Options|Qt Versions dialog. The new installation was recognized, but only because it was in the PATH variable, not because I manually added it there. Furthermore, building some of my own projects from scratch proved to be successful and the resulting executables are completely autonomous with no additional Qt dependencies. When switching the Qt version used from the Project's properties to the original, shared-linkage version of Qt, building also completes successfully and the executables run perfectly from inside Qt Creator's environment (but not from a Windows Explorer window, as is expected).
At this point, it seems that my original objective should be considered completed, since I could start Qt Creator from a customized batch file that also sets up the environment for it to properly locate the static Qt installation. But, what if someone would like to use more than two Qt installations? I don't think that multiple batch file configurations is what the Trolls had in mind when designing the Qt Versions feature of Qt Creator!
So, the next step in my experiments was to determine if there's a the possibility that Qt Creator failed to locate the static Qt installation when adding a manual entry for it, because Qt Creator is searching there for some files which are either missing or have different relative paths or different contents than what is expected. Remember the qt-win-opensource-4.6.1-mingw.exe" I mentioned in #5? I reinstalled from it, in the default target directory (C:\Qt\4.6.1). Then started Qt Creator from its normal shortcut inside the Qt SDK's Program Group. And guess what? In the Qt Version dialog, this third installation of Qt is properly recognized when trying to add a manual entry for it!
qtcreator02.png
Any thoughts on where to go from here to get to the bottom of this? Thanks!
That's good. It's exactly what should be there. DLL files are dynamic libraries and you want static ones.
What does qmake -v return when ran from the default (non-Qt) command prompt?
And when you add it there then it is not recognized?The new installation was recognized, but only because it was in the PATH variable, not because I manually added it there.
The question is a bit pointless as Trolls didn't indend it to be dependant on the PATH contents. You must have done something wrong.But, what if someone would like to use more than two Qt installations? I don't think that multiple batch file configurations is what the Trolls had in mind when designing the Qt Versions feature of Qt Creator!
Same as post #3, dependency upon libgcc_s_dw2-1.dll.
It is, but only for the current running instance of Qt Creator. Closing Qt Creator and restarting it from its normal shortcut, that entry is again reported as an invalid Qt installation.And when you add it there then it is not recognized?
I agree with you! That's why I keep pursuing this matter even after having written the following:The question is a bit pointless as Trolls didn't indend it to be dependant on the PATH contents. You must have done something wrong.
At this point, it seems that my original objective should be considered completed, since I could start Qt Creator from a customized batch file that also sets up the environment for it to properly locate the static Qt installation.
EDIT: I tried copying libgcc_s_dw2-1.dll next to qmake.exe (inside C:\Qt\2010.01-Static\bin). Now Qt Creator, when run from its normal shortcut of course, is able to recognize the static Qt installation by pointing to qmake.exe.
qtcreator03.png
But, every project that is built with this configuration ends up with a dependency upon libgcc_s_dw2-1.dll.
Does this mean that I have to rebuild a static version of QMake and if so, how can I do this? Wasn't it supposed to have been taken care of when I configured and built Qt from the sources? Or was the use of the dynamic Qt installation's command prompt environment to build the static Qt, an error in the first place? Please, do not be intimidated by the many and tightly packed questions, I'm just venting a little frustration! And thank you wysota, for bearing with me so far!
Last edited by parsifal; 25th January 2010 at 18:46.
.
So copy that library to a place where the linker can find it.
Because the gcc library can't be found. That's nothing unexpected.It is, but only for the current running instance of Qt Creator. Closing Qt Creator and restarting it from its normal shortcut, that entry is again reported as an invalid Qt installation.
It's not hard to reach this part of MinGW docs:But, every project that is built with this configuration ends up with a dependency upon libgcc_s_dw2-1.dll.
Originally Posted by MinGW docs
Last edited by wysota; 26th January 2010 at 08:54.
Bookmarks