Configure Qt Creator for switching between dynamic and static linkage

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