QT Creator for plain C++ under windows, executable complains about missing DLL
-
Hello,
sometimes i need to make smaller console programs. They are simple enough that i don't need Qt for them, but i still want to use Qt Creator for development.Development and debugging is fine, but i can't run the built exe file outside of creator. (build in release mode, of course)
Double clicking on the exe i'm presented with an "impossible to find entry point" dialog.The project is being getting compiled with the Qt 6.10 MinGW Kit
Initially i thought the problem was me using MinGW instead of MSVC. Same issue with the LLVM and MSVC kits.
Instead, if I build the project with plain MinGW (copy CMakeList.txt and source files in another folder, use VSCodium's CMake plugin), i get a working executable.I'd like to understand what i'm doing wrong:
- Is using a Qt kit to build a non-qt application the problem?
- Can/Should i add plain MinGW as a "kit"?
- Is there a way to do what i want with Qt Creator? Because while i can use VSCodium or another IDE for debugging, i really prefer Qt Creator's interface.
Thanks
-
Hi @monegator
I'm currently not sure what exactly your problem is, but:
Is there a way to do what i want with Qt Creator?
For sure, I have done this a dozen times.
I'd suggest you create a "Hello World" plain C / C++ program from Creators Wizard for Test. To run standalone, you'll need the MinGW runtime DLLs (I can look that up tomorrow when I'm back on a Windows machine).
Some more hints:
Is using a Qt kit to build a non-qt application the problem?
No, but your make script should not reference Qt. I mostly use Qmake, there you have to specify
CONFIG -= QT. The Creator wizard should set that up correctly.Should i add plain MinGW as a "kit"?
I have never needed that.
Regards
-
@monegator So I've checked on a Windows machine that has MinGW 8.1 32 bit. On that machine I created a Hello World Program with
File > New Project > Non-Qt Project > Plain C Application, build that and could run it outside Creator without any DLL deployment.But in case MinGW DLLs are needed, you will find them under
c:\Qt\Tools\mingw810_32\bin(replacemingw810_32with your version).If it still does not work, then please provide the exact error message for further investigation.
Regards
Qt has to stay free or it will die.
-
@monegator So I've checked on a Windows machine that has MinGW 8.1 32 bit. On that machine I created a Hello World Program with
File > New Project > Non-Qt Project > Plain C Application, build that and could run it outside Creator without any DLL deployment.But in case MinGW DLLs are needed, you will find them under
c:\Qt\Tools\mingw810_32\bin(replacemingw810_32with your version).If it still does not work, then please provide the exact error message for further investigation.
Regards
-
Hi guys, thanks for answering :)
I transitioned to CMake between Qt5 and Qt6, so i didn't even try the QMake approach
I was unable to find the missing DLLs, thanks to pointing to where they're at, nor what their name was (dependency walker did not help here, because all i got was mangled names)One interesting thing, then: VSCodium's CMake build will produce a self contained exe (~600kB instead of ~100) so what i probably want is a static build?
-
Hi guys, thanks for answering :)
I transitioned to CMake between Qt5 and Qt6, so i didn't even try the QMake approach
I was unable to find the missing DLLs, thanks to pointing to where they're at, nor what their name was (dependency walker did not help here, because all i got was mangled names)One interesting thing, then: VSCodium's CMake build will produce a self contained exe (~600kB instead of ~100) so what i probably want is a static build?
@monegator
cmake does nothing but invoke compilers/linkers per the rules it is given. It doesn't affect anything itself. I would start by getting it to show the full compiler/linker lines it is executing (and showing its exported environment variables would also be useful). Then you will know what is actually being done. You can see whether e.g. one is a static link and the other a dynamic one, and (hopefully) why it produces something workable in one case but not another.
