Puzzled by windeployqt's choice of DLL to include, and why QtCreator didn't uninstall too
-
I've been successfully building a Qt desktop app on Windows using Qt5.6 for some months now. It's via a fairly straightforward qmake + nmake + windeployqt build script. I use the mscv2013 32-bit stuff.
Windows is the last version I get around to building after OSX and Linux and iOS. It's not my main platform and I'm not that familar with its quirks.
All was well until I decided to run the MaintainanceTool for the first time in a while to update the Qt5.6, and grab 5.7 too with the intention of seeing if there was any good reason to update to it. I notice some new QtCreator stuff came in too. I didn't pay much attention as I don't use QtCreator (but I don't actively oppose its updates either).
I tried to build and run my application with Qt5.7 and got some dialog about "The procedure entry point ?qlsEffectiveTLD<mangled stuff> could not be located in the DLL <my deplyment folder>\QtNetwork.dll.
I promptly reverted to Qt5.6 in the path, rebuilt from clean, and got the same problem when I ran it again.
I fired up the maintainance tool and uninstalled Qt5.7 and QtCreator. Rebuilt from clean and... yes, still got the same problem.
At this point I went looking for QtNetwork5.dll versions. What really surprises me is:
- there's still a copy, and indeed a ton of other stuff, in C:\Qt\Tools\QtCreator\bin\ , despite me thinking the MaintainanceTool uninstall must have nuked it.
- There's another copy of QtNetwork5.dll at C:\Qt\5.6\msvc2013\bin, but the copy which seems to be being copied into the deployment folder by windeployqt is the QtCreator one!
(In fact looking at the DLL metadata, yes the QtCreator one is 5.7.0. But why is the 5.6 windeployqt picking up a 5.7 DLL? I just did a search of the entire machine to see if windeployqt was maintaining a sneaky tmp cache somewhere which might need cleaning out, but didn't find anything)
Is there some sane explanation of what's going on here, and a fix/workround?
-
Hmmm problem fixed itself as mysteriously as it started when I got a fresh cmd.exe to do the build in. Going to guess it's something to do with accumulated impact of running repeated .bat files, and windows not running them as subshells like the more unix-world systems I'm used to.
Tempted to delete the above but will leave it here in case anyone else recognises it. I am still a bit surprised MaintainanceTool didn't remove all trace of QtCreator when asked to uninstall it.
-
Hi,
Which installer did you use ?
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
How are you calling windeployqt ? Are you doing any special setup ?
Are you calling the 5.6 windeployqt on your 5.7 built application ?
-
Aha: I was calling build and deploy from separate batch files. Both of which begin with
setlocal SET PATH=%PATH%;C:\Qt\5.7\msvc2013\bin;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin ....This was working fine so long as PATH didn't have any Qt 5.6 or 5.7 binaries in PATH already. But then I think I manually set PATH in one of the cmd.exe windows I was using to try something more finer-grained than the full build script. Of course from that point batch files invoked from that window were doomed to use whichever version of Qt I'd selected in the window's PATH, not the one in the script. And just to make things super-confusing I had another window open which didn't have a PATH with Qt in, but was expecting them to behave the same.
Changed the scripts to
SET PATH=C:\Qt\5.7\msvc2013\bin;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin;%PATH%:^)
-
That's also what Qt Creator does when setting up the environment for the Kit you are using :)
