Try opening the shared library with dlopen () and see if it loads, and if not, what dlerror () says. I have always encountered similar problems on Windows. LoadLibrary () / GetLastError () saved me many times (the last time it was due to the wrong version of some libiconv / libintl library). Running ldd in the plugin can also help.
If the dlopen () function works fine, try downloading the plugin from QPluginLoader. If it does not load, check the plugin build file. I usually do this in a dirty way by running lines in the plugin and then looking for lines like "buildkey" or "QT_PLUGIN_VERIFICATION_DATA". Just looking at and around the assembly key may give you an idea. For example, you can understand that you compiled your plugin in release mode when the application was compiled in debug mode. In this case, the build key will not match and the plugin will not load. Everything in the build key should match your configuration. Please note that the version and assembly key are checked differently: the assembly key must match exactly (or match black magic called QT_BUILD_KEY_COMPAT), but in the version only the main version must match exactly, the younger version must be the Qt version, the plugin was compiled with or later , and the patch level is ignored. Therefore, if your plugin was compiled with Qt 4.xy, then it will work with versions of Qt 4.z. *, where z> = x. It really makes sense.
If the build key looks fine (which is unlikely if you get to this point), you can look at the source code of QLibraryPrivate :: isPlugin () to see whatโs wrong, but it doesnโt look easy (although doing this in the debugger may help).
If QPluginLoader loads the plugin, check if it is in the correct directory and has the correct permissions. If you still haven't solved the problem until now, it's time to take a look at the source code of the SQL module that actually loads these plugins. But this is extremely unlikely. I came across this problem many times, and it was always either a library that was not loading, or a build key that was not appropriate.
Another way to go after QPluginLoader loads the plugin successfully is to use strace to find out if the program is at least trying to open the plugin file. Searching for something like "sqldrivers" or "plugins" in the strace output should also return the directory in which Qt looks for its plugins and, in particular, SQL drivers.
Update
Is it possible to compile the driver as a static plugin and not worry about anything? Try:
d:\Qt4\src\plugins\sqldrivers\psql>qmake CONFIG+=static LIBS+=-Ld:/programs/Post greSQL/lib INCLUDEPATH+=d:/programs/PostgreSQL/include d:\Qt4\src\plugins\sqldrivers\psql>make
It compiles fine, and now I got libqsqlpsql.a (release) and libqsqlpsqld.a (debug) in QTDIR / plugins / sqldrivers (this is the right place on Windows). I use the PostgreSQL driver here, but I do not think that for MySQL it will be completely different, which I just did not install. Well, let him compile some real program with him:
d:\alqualos\pr\archserv>qmake QTPLUGIN+=qsqlpsql PREFIX=d:/alqualos LIBS+=-Ld:/g nu/lib INCLUDEPATH+=d:/gnu/include LIBS+=-Ld:/programs/PostgreSQL/lib LIBS+=-lpq
Please note that I had to manually link to libpq, otherwise the linker will complain about undefined links. The funny thing is: qmake knows that qsqlpsql is in QTDIR / plugins / sqldrivers and accordingly sets the compiler and linker options. Therefore, it should still be in the right place to work, only you do not need to worry about the fact that your users are faced with the same problem as during compilation. An alternative would be to simply use LIBS+=-Lpath/to/plugin LIBS+=-lqsqlpsql instead of QTPLUGIN+=qsqlpsql , at least the docs say it should work, but I haven't tested it.
In order for the application to really use the plugin, I had to put the following into my main block (CPP file):
#include <QtPlugin> Q_IMPORT_PLUGIN(qsqlpsql)
It works! In addition, from what I was able to find out from the sources, the build key and version are checked only when the plugin is dynamically loaded (all relevant materials are in the private QLibrary class, not even QPluginLoader). Thus, the resulting executable file may (or may not, depending on binary compatibility) work even with different versions and strings of Qt, although using it with older versions may cause some errors that were fixed later.
It is also worth noting that the order of loading the SQL drivers is as follows: use the driver statically linked to Qt, if available, then find the driver registered manually with QSqlDatabase :: registerSqlDriver (), then find the driver statically imported into the application (the method described above), and finally try to download the generic plugin. Therefore, when you link statically, your users will not be able to use dynamically linked drivers that they already have, but they will be able to use drivers linked statically in Qt (for example, in Ubuntu).