Configure Qt Creator for switching between dynamic and static linkage

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