Configure Qt Creator for switching between dynamic and static linkage

[parsifal]

Hello friends! I am trying to accomplish exactly what the OP of this thread asked, only I'm using Qt Creator on Windows to code and build my programs. So, I think it's a matter of properly buiding a static version of Qt and setting up Qt Creator to recognize and use this version of Qt. Here's what I have done so far:

1. Installed the latest version (2010.01) of the complete Qt SDK with MinGW compiler from Nokia. Target installation directory was C:\Qt\2010.01. This installation works perfectly and I can code and build versions of my programs with shared linkage with no problems
2. Downloaded the latest version (4.6.1) of the Qt sources only from ftp://ftp.qt.nokia.com/qt/source/. The exact filename is qt-everywhere-opensource-src-4.6.1.tar.gz
3. Created a second directory named C:\Qt\2010.01_Static and extracted there all the contents of the above tarball
4. Using the Qt Command Prompt from the already installed Qt SDK, I navigated to C:\Qt\2010.01_Static and built a static version of Qt following these instructions
5. Ran Qt Creator, opened Tools > Options... > Qt4 > Qt Versions and tried to add a new "item" indicating the static version of Qt to be used

After pointing to the location of qmake.exe inside C:\Qt\2010.01_Static, it seems that Qt Creator does not recognize this static build of Qt:

qtcreator.png


Any hints on what am I missing here?

TIA,
parsifal

[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?