Qt MySQL driver: entry point not found

starryeyed

I have just fixed my deployment process, commited everything in a working state to a local git, and after playing a bit with the .pro file (tried changing INCLUDEPATH), I've broken the deployment on my own machine...
Removing build-folders and making a git reset --hard to a previously made checkpoint changed nothing.
Somehow, all my previous deployment issues were related to MySQL C Connector, and now it's qsqlmysql.dll...
So, from Qt Creator it launches normally. Here's a shot of launch outside of Qt Creator, on dev. machine
The gibberish text I'm sure stands for "entry point not found".
Here's a shot from Windows 7 VM, way less verbose
Here's a log of Dependency Walker ran inside the VM, because on dev. machine it unfortunately hangs while the profiled app is loading IMM32.DLL

SGaist

Hi,

Did you check whether there's a mismatch between debug and release .dlls deployed ?

starryeyed

This post is deleted!

starryeyed

@SGaist I have just copied the whole deployment directory back to my dev. machine from a machine that worked OK yesterday. Now it launches outside of Qt, but how do I fix this retarded problem? Why when I tried to collect dlls with windeployqt yesterday, the copied files were OK, and now, even though I've removed Qt completely and installed it back just to be sure, it will collect the wrong ones? Maybe I should replace the dlls in QTDIR with the ones I've just recovered?
Also, an issue remains unresolved. For unknown reason, I've so far succeeded only in launching my app on Windows 10. When I try on 7 & 8, the driver is not loaded... Without much console output about, nothing descriptive at least.
Here are console outputs for comparison:

QFactoryLoader::QFactoryLoader() looking at "C:/Users/starryeyed/Documents/build-release/release/sqldrivers/qsqlmysql.dll
Found metadata in lib C:/Users/starryeyed/Documents/build-release/release/sqldrivers/qsqlmysql.dll, metadata=
{
    "IID": "org.qt-project.Qt.QSqlDriverFactoryInterface",
    "MetaData": {
        "Keys": [
            "QMYSQL3",
            "QMYSQL"
        ]
    },
    "className": "QMYSQLDriverPlugin",
    "debug": false,
    "version": 330240
}
Got keys from plugin meta data ("QMYSQL3", "QMYSQL")

loaded library "C:/Users/starryeyed/Documents/build-release/release/sqldrivers/qsqlmysql.dll"
QFactoryLoader::QFactoryLoader() checking directory path "C:/Users/starryeyed/Documents/build-release/release/accessible" ...
QFactoryLoader::QFactoryLoader() checking directory path "C:/Users/starryeyed/Documents/build-release/release/accessiblebridge" ...

And this is what comes up on target machines with Windows 7 or 8 (I've checked that MSVC++ 2015 Red. is installed btw):

QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7

P.S. Watching the .exe with Process Explorer I've noticed that on dev. machine it shows all dlls the application needs, while on VM it shows none of dlls...
P.P.S. As the log of Dependency Wlaker from the 1st post shows, on VM the app would just crash while profiling with access violation in QT5CORE.DLL. Is it a quirk of DW or does it actually matter?

SGaist

Since you are talking about visual studio, do you have the runtime installed on the target machines ? If not installed, are you providing them with your application ?

starryeyed

@SGaist please don't mistake MSVC and MSVS :) I said "MSVC++ 2015" to abbreviate Microsoft Visual C++ Redistributable 2015, which is indeed installed on target machines. As I've learned, it is needed to run this app, though Windows 10 has it preinstalled so I don't have to bother in that case.
Now, there is no Visual Studio involved, only Qt Creator.
How to tell a difference between launching on a target Windows 10 machine and a target Windows 7 machine? Because Dependency Walker doesn't really go well with profiling Qt apps, at least from my impression.

starryeyed

@SGaist I have successfully deployed onto a 32-bit Windows 7 VM, yet to see how real target machines do, but I'm pretty sure I'm good.
Can you imagine? The key to revealing the mystery of missing dlls was NOT in Dependency Walker, but in Process Explorer!
I don't want to say anything bad about DW, it just derailed the whole investigation. It has pointed to vcruntime140.dll, which as you said belong to MSVC++ 2015, when actually what was missing, at least from Windows 7 VM, was MSVC++ 2013.
Attaching a screenshot from ProcExp.