Qt application from Linux to Windows
I have an application that runs perfectly in Linux environment. Now, I would like to port it to Windows. I installed Qt for Windows and tried to build (MinGW) my application. With some minor modifications, I was able to build my app and to run it from within creator. Next step : run it outside creator. And here, I got stuck… I get an error message : “The procedure entry point _z20qt_qFindChild_helperPK7QObject…… could not be located in the dynamic link library QtCore4.dll”. First thought : it cannot find the DLL. So, I copied QtCore4.dll from \path\to\qt\bin to the same folder as my app. Still get the same error message. What am I doing wrong ?
I used Dependency Walker to look for missing DLL’s. There are still other Qt dll’s that it can’t find. I added them all to the same folder as my app. Still the same problem. The only missing dll’s according to Dependency Walker are MSVCR90.DLL, IESHIMS.DLL and WER.DLL. These look as system dll’s to me. Don’t know why it can’t find these… and if they are really necessary for my app
First I have to say that I’ve never met this problem.
But for me, it was sufficient to copy all QtXXX4.dll (corresponding to Qt Modules I use within my app) to same folder where my output binary is placed.
Don’t have much exps with this, but I would blindly suggest to you to try rebuilding your app and test debug/release … based on what qt you have installed/build.
And … do you have a complete Qt SDK bundle (with Qt Creator) or did you installed qt framework libraries and qt creator separately (maybe messed up versions)?
Good for you.
But I have tried to verify what I’ve posted before and found that it is not true – I reproduced your error and wasn’t able to resolve it.
Without environment path pointing to qtdir/bin and qtdir/mingw/bin. I was unable to launch application failing on “The procedure entry point…” error.
Maybe it could be relevant to say that now I was testing it on Windows 7 64bit.
Based on Deploying an Application on Windows [doc.qt.nokia.com] i copied all needed dlls (Core,Gui,Network in my case) and mingwm10.dll for mingw runtime.
I even placed all contents of qtdir/bin and mingw/bin to directory with my_app.exe but it didn’t helped!
So question for others:
Is this some kind of bug, or are we missing something in deployment process?
I work with Qt on Windows most of the time. This is a general issue that you can run into with every dll. If you get the procedure entry point error, there is a wrong dll called. This can happen if the wrong version of a dll is copied to your application path, but also when a dll is loaded that is in your PATH.
The actual entry point could point to which dll is actually the problem.
… But, I still don’t have any idea why it is running now and not before …
It’s beacause when installing Qt this time you had set up PATH env variable to point to your Qt directory you installed – and to correct dlls. I was testing it now because it seemed strange to me that only copying dlls is not enough (i will need to distribute my app in very near future so i got scared/interested ;)).
PATH. …… If you get the procedure entry point error, there is a wrong dll called. This can happen if the wrong version of a dll is copied to your application path, but also when a dll is loaded that is in your
Oh good point, thanks.
This was good hint, i found another question here [developer.qt.nokia.com] and i noticed what was the problem.
The solution is to copy required dlls next to your app exe:
- mingw dlls
- from C:\Qt\2010.05\mingw\bin
- Qt dlls (based on modules used in your app)
- from C:\Qt\2010.05\*qt*\bin (! not from C:\Qt\2010.05\bin)
So I copied the wrong dlls (missed the qt subdir) – now it runs ok.
Maybe fva has made same mistake as I did, or maybe he missed some dlls his app needs and they got loaded from other place in PATH (system32 and so).
The qt\bin is indeed the one you need. The bin directory is the one used by qtcreator, moc, uic and whatnot. These can be different versions on windows. M$ are being an ass by letting the developer solve the dll hell. Of course there can be problems with truly shared dlls as well, given the ever increasing amount of closed source dynamically linking applications. from C:\Qt\2010.05\*qt*\bin (! not from C:\Qt\2010.05\bin)