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:
Edited the \mkspecs\win32-g++\qmake.conf file, and built:Originally Posted by C:\Qt\2010.01-Static\configure_parsifal_static_qt.cache
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:mingw32-make sub-src
From inside the modified command prompt's environment, I navigated to C:\Qt\2010.01-Static\examples\draganddrop\puzzle and entered:Originally Posted by C:\Qt\2010.01-Static\bin\myqtenv.bat
...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).qmake
mingw32-make
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?
Bookmarks