Configure Qt Creator for switching between dynamic and static linkage

[wysota]

What does qmake -v from the new directory return?

[parsifal]

When run from a default system's command prompt, a messagebox with the following content:

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

When run from the Qt SDK's command prompt:

C:\Qt\2010.01_Static\bin>qmake -v
QMake version 2.01a
Using Qt version 4.6.1 in C:/Qt/2010.01_Static/lib

[wysota]

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.

[parsifal]

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!

[wysota]

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.

[parsifal]

Open those examples in Dependency Walker to see what they depend on.

For the Puzzle example (examples\draganddrop\puzzle), it's QtCore4.dll and QtGui4.dll.

Also inspect your Qt libraries to see if they are indeed statically built.

How would I go about doing that?

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.

[wysota]

For the Puzzle example (examples\draganddrop\puzzle), it's QtCore4.dll and QtGui4.dll.

Did you distclean the directory and reran qmake before compiling them?

How would I go about doing that?

Output of dependency walker, size and extension of the library file are relevant.

Moreover, isn't configuring and building Qt according to these instructions the proper way to get static versions of the Qt libs?

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.

[parsifal]

Did you distclean the directory and reran qmake before compiling them?

Relied on Qt Creator for this: Right clicked on the project entry and selected "Clean".

Output of dependency walker, size and extension of the library file are relevant.

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.

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.

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.


Thank you for your advices so far, I will get back with more information.

[wysota]

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.

Qt Creator works, it's the Qt installation that (probably) doesn't work. So don't test Qt Creator, test Qt. Eliminate the irrelevant factor - which in this case is Qt Creator.

[parsifal]

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:

-static
-release
-no-exceptions
-no-phonon
-no-phonon-backend
-opensource
-saveconfig
parsifal_static_qt

Edited the \mkspecs\win32-g++\qmake.conf file, and built:

mingw32-make sub-src

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:

set QTDIR=C:\Qt\2010.01-Static
set PATH=C:\Qt\2010.01-Static\bin
set PATH=%PATH%;C:\Qt\2010.01-Static\bin;C:\Qt\2010.01\mingw\bin
set PATH=%PATH%;%SystemRoot%\System32
set QMAKESPEC=win32-g++

From inside the modified command prompt's environment, I navigated to C:\Qt\2010.01-Static\examples\draganddrop\puzzle and entered:

qmake
mingw32-make

...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).

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?

[parsifal]

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!

[wysota]

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.

That's good. It's exactly what should be there. DLL files are dynamic libraries and you want static ones.

I tried again to make Qt Creator recognize the second Qt version/installation.

What does qmake -v return when ran from the default (non-Qt) command prompt?

The new installation was recognized, but only because it was in the PATH variable, not because I manually added it there.

And when you add it there then it is not recognized?

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!

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.