Undefined symbols for architecture arm64: "qt_static_plugin_qsqlite()"

chopper

I've built a utility library that has a storage system that currently uses Qt's sqlite support.
On linux, windows, and macos - everything works great and exactly as expected provided the runtime dependencies are in the correct location - the test client application runs great and Sqlite works great.

On iOS; however, I'm having problems.

I'm using 5.11.1 and the device I'm targeting is arm64.

Everything builds and links fine - but at runtime I get the "SQL driver not loaded error" - which leads me to the forums where I learn that I'm supposed to do 3 things for iOS because it's a static Qt build (I'm using the Qt built iOS libraries, I did not build them myself.)

Add Q_IMPORT_PLUGIN( qsqlite ) to my utility library's source code
Add QTPLUGIN += qsqlite to my utility library's pro file.
In XCode - add libqsqlite.a to the linked frameworks and libraries of the test client (making sure the ios/plugins/sqldrivers directory is in the library search path of XCode)

This, unfortunately leaves with with the linking error shown below when building the test client:

Undefined symbols for architecture arm64:
  "qt_static_plugin_qsqlite()", referenced from:
      StaticqsqlitePluginInstance::StaticqsqlitePluginInstance() in libmyutility.a(vault.o)
      StaticqsqlitePluginInstance::StaticqsqlitePluginInstance() in libmyutility.a(storageimplementationsqlite.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I am, of course, assuming that the missing symbol is actually defined in the linked in sqlite plugin (libqsqlite.a) - is that wrong?

XCode can be pretty weird some times, so I worried that it was failing to read the plugins directory some dumb caching reason, so I copied the libqsqlite.a lib to the regular qt libs directory in a vain attempt to ensure that the linker could find it (it finds all the other Qt objects there just fine for iOS) - but that didn't fix the problem either.

I saw some confusing but unanswered questions in some threads where people were asking if you no longer need to use Q_IMPORT_PLUGIN anymore - but I really don't know for certain what I should or should not be doing.

Any help from someone who is using Qt's Sqlite support on iOS would be appreciated - thanks.

chopper

Dumping symbols via:

nm libqsqlite.a | c++filt

yields:

libqsqlite.a(smain.o):
---------------- T qt_static_plugin_QSQLiteDriverPlugin()

chopper

No one uses qt's sqlite support on iOS?

Well, I guess I'll check to make sure the lib is actually a universal binary and that it doesn't work on the x86 simulator as well...

chopper

Well, the lib has all the necessary architectures, but fails with same error when building for simulator except the symbol is missing for x64/x86.

So, I open up QtCreator and I load up the 'books' example, and build it for iOS - it builds fine, and it runs fine.

I search through the PRO file, and the source code - there's no Q_IMPORT_PLUGIN and there's no QTPLUGIN entry at all.

It simply adds sql to the config.

This is clearly contradictory to what I've been reading here in the forums - what's up with that?

chopper

So I removed all the stuff that I'd seen forum posters say you needed, and just used the settings that appear identical to the books example (which uses the "QSQLITE" driver) but doesn't do anything relating to importing plugins.

I get my original problem again: "QSqlDatabase: QSQLITE driver not loaded", and when I ask QSqlDatabase::drivers() for a list of drivers, there are none. When I do that in the books example I get "QSQLITE."

...hmmm... I've just noticed an extra CPP file being generated in the resulting XCode project from QtCreator via Qmake:

That file contains the following:

Q_IMPORT_PLUGIN(QSQLiteDriverPlugin)

I'll give that a try, not sure where I should have found that plugin name though...

chopper

Well, surprise, surprise - using Q_IMPORT_PLUGIN(QSQLiteDriverPlugin) was what needed to be added.

Hope this helps someone doing the weird things I'm doing (building a C++ library, in turn wrapped in an objective-c framework, used by a swift client.)