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?

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

[parsifal]

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

Same as post #3, dependency upon libgcc_s_dw2-1.dll.

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

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.

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.

I agree with you! That's why I keep pursuing this matter even after having written the following:

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!

[wysota]

Same as post #3, dependency upon [I]libgcc_s_dw2-1.dll

.
So copy that library to a place where the linker can find it.

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.

Because the gcc library can't be found. That's nothing unexpected.

But, every project that is built with this configuration ends up with a dependency upon libgcc_s_dw2-1.dll.

It's not hard to reach this part of MinGW docs:

Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw
exceptions between different modules, such as between two DLLs or a
DLL and an EXE. Consequently, it is the default for all languages
other than C. To disable this dynamic linking, use -static-libgcc.
To enable this dynamic linking in C, use -shared-libgcc.

[parsifal]

So copy that library to a place where the linker can find it.

No copy is necessary, the problem with the libgcc_s_dw2-1.dll dependency in the projects can be resolved by simply adding the line:

QMAKE_LFLAGS += -static-libgcc

in the respective .pro files.


As for the problem with qmake.exe not running correctly from a standard command prompt (and thus Qt Creator not being able to correctly locate the static Qt installation), I managed to have configure build a completely static version of QMake, by editing the files Makefile.win32, Makefile.win32-g++ and Makefile.win32-g++-sh (didn't know exactly which of the 3 would be actually used when configure builds QMake) inside the \qmake subdirectory:

LFLAGS = -static-libgcc

Now, one step remained for making the tweaking of .pro files unnecessary: Editing \mkspecs\win32-g++\qmake.conf to add:

QMAKE_LFLAGS = -static -static-libgcc -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc

I verified by, yet again, starting from scratch with a freshly extracted source tarball, making the aforementioned changes and building Qt. The results:

1. Qt Creator picks up correctly the static Qt installation from its version management panel
2. You can switch between Qt Versions being used for the building of a project, without the need to manually tweak the .pro file or arbitrarily copy files inside the new Qt installation's directory. The static executable produced has no external Qt or MinGW dependencies whatsoever.


After all the above, may I propose that an addition be made to the Wiki article, incorporating the 2 changes I mentioned and by doing so, providing a clean, out-of-the-box solution? It seems that the introduction of GCC 4.4 in the most recent versions of Qt created the extra dependency upon libgcc_s_dw2-1.dll and the article in its current form deals only with the mingwm10.dll dependency (if only I had arrived to this conclusion earlier!). I will do it myself, but since I'm new here, only after a respectable member of the community verifies my findings and gives the Go signal.


wysota, thanks for the hints, they were really helpful to get to the bottom of this!

[wysota]

You can edit the article if you want.

[parsifal]

Just did, hope I didn't make a mess...