There is no Qt runtime. You can install all needed Qt libraries system wide (create an installer for that), so all your Qt applications can access them.

@JonB Thanks Jon. I will look into those suggestions. I think at this point though, the best thing for me to try, rather than thrashing around with my current project, would be for me to start a new project focused on just replicating this specific issue. I'll try and pare this down to minimal required code, just enough to reproduce the problem This will make findings clearer and easier to communicate to others. If I get to a point where I have something useful to share, I'll do so. Thank you again..Mark

@JonB it works bro thank you problem fixed when i tried this before it doesn't open the window at all ... just flashing but now i understand why it's working Thank you <3

Just a note about a non-Valgrind, windows-specific leak-checking method: https://docs.microsoft.com/en-us/visualstudio/debugger/finding-memory-leaks-using-the-crt-library?view=vs-2019 It has been a while since I have done any extensive work on a Microsoft platform, but in my recollection crtdbg.h can do many helpful diagnostic things, although it is sometimes tricky to get all the debug build settings configured in the way that will trigger the features you seek.

Thanks for this hint. Very useful for debugging purposes. Appreciate the help :)

@Persivan said in QMYSQL driver not found after release: Any ideas? Yes, use search function in this forum - this is asked so often. Most probably the MySQL driver lib is missing.

@sierdzio I think you're second option is correct. I did dumpbin /dependents on both the debug and release versions of my util, and they have the same release QT dlls. I guess I never had to step into the QT code :-) . Usually, I get link errors when mixing debug with release, stemming from different array instrumentations. Sounds like QT was careful about this, to allow the mixing of debug with release -- unix-like.

I ran into the same problem: VS2017, Qt 5.12.6, Windows 10, Release, static inline const QString member. interestingly, using QStringLiteral around the initializer makes the problem go away, so it seems to have something to do with memory allocation.

Ok, I've found that the results are stored in files Makefile.Release, Makefile.Debug and everything is explained here.

Thank you for your answer!

You should check this: http://doc.qt.io/qt-5/windows-deployment.html Especially the "The Windows Deployment Tool" part.

Whew! I think I got it... The mistake was to use the includes of shared \build_dev when building in release. There is only one little difference which made everything work: qconfig.h! It defines QT_STATIC in the static \build_app1 ... The debug config of the project created by the Qt Add-in has to be adjusted a little though: Include directory $(QTDIR$)\include =>...\build_dev\qtbase\include. Lib directory $(QTDIR$)\lib =>...\build_dev\qtbase\lib. The project still uses \build_app1\qtbase as Qt Version. That way, the Debug build looks for includes and libs in \build_dev while the Release build looks in \build_app1. And the .lib symlinks are not necessary anymore, I just kept the bin directory symlink. Just in case someone else wants to do something like this...

@JKSH It is latest version of MinGW. But everything works fine with Qt version of MinGW. Thank you so much for help!

Finally fixed it, i used a .qmake.conf file to store the root directory in a shared variable, for those who are interested, here are my 3 .pro files : project.pro TEMPLATE = subdirs CONFIG += ordered c++11 SUBDIRS = ircbot \ myApp myApp.depends = ircbot mylib.pro DESTDIR = $$lib_dir TARGET = mylib TEMPLATE = lib CONFIG += staticlib SOURCES += ... HEADERS += ... FORMS += ... myApp.pro DESTDIR = $$bin_dir TARGET = myApp TEMPLATE = app LIBS += $$lib_dir/libmylib.a INCLUDEPATH += ../mylib SOURCES = ... HEADERS += ... FORMS += ... and finally, the .qmake.conf file : lib_dir=$$PWD/lib bin_dir=$$PWD/bin this successfully creates this project structure : bin myApp.exe lib mylib.a project.pro .qmake.conf myApp myApp.pro mylib mylib.pro + a build directory anywhere i want

Oh, I guess when not using -openssl-linked, it will not matter as the .lib files will not be used. I'm still interested in what to do if I'd actually want to use -openssl-linked.

Thank you everyone :) I followed simow and SysTech's suggestions and used QDebug to find the problem. I found my program crashed when entering a certain set of libraries so I ran the release executable through the debugger. The stack trace of the assembly revealed that my code was using the debug versions of my third party dlls even though I thought I specified my project to not use them in the release version. I modified the .pro file in qtcreator and now everything works properly. Thanks!!!