Red Hat Bugzilla – Bug 770399
undefined reference to QPSQLDriver::QPSQLDriver(pg_conn*, QObject*) in qt-postgresql-4.8.0-0.29
Last modified: 2011-12-27 12:41:02 EST
Description of problem: Linking with the qt Postgresql Driver (version qt-postgresql-4.8.0-0.29) does not provide the custom constructor QPSQLDriver::QPSQLDriver(pg_conn*, QObject*) at link time, although it's present in the header file and in the QT Postgresql source package distributed. Version-Release number of selected component (if applicable): 4.8.0-0.29 How reproducible: Always Steps to Reproduce: 1.Use the following source: #include <stdio.h> #include <stdlib.h> #include <QObject> #include <QtSql/QSqlDatabase> #include <QString> #include <libpq-fe.h> #include <QtSql/qsql_psql.h> int main() { PGconn* f_connection = PQconnectdb( QString( "host=localhost user=%1 password=%2 dbname=%3" ) .arg( "username" ) .arg( "password" ) .arg( "database" ) .toStdString() .c_str() ); QPSQLDriver* f_driver = new QPSQLDriver( f_connection ); QSqlDatabase::addDatabase( f_driver ); return 0; } 2.compile 3.link Actual results: A linker error: undefined reference to QPSQLDriver::QPSQLDriver(pg_conn*, QObject*) Expected results: Successful compilation
This is private undocumented API and thus not exported from the shared library. (The symbol has hidden visibility.)
(From the QSqlDriver documentation: "This class should not be used directly. Use QSqlDatabase instead." And QPSQLDriver is a database-specific subclass of QSqlDriver, thus even more private.)
There seems to be an inconsistency in the Qt documentation itself, please see here: http://developer.qt.nokia.com/doc/qt-4.8/qsqldatabase.html#addDatabase-2 This is an intended behaviour -- the users access the underlying DB connection, utilizing advanced features (or, in my own implementation, the COPY statement) alongside the Qt API for SQL. What is the original policy here? Should the API be allowed or not? I have fixed my urgent problem with duplicating the QPSQLDriver code in my application, adding the changes needed to access the connection directly. Thus, I'm leaving the bug as closed.
The upstream documentation you linked also says: "If you do this, it is recommended that you include the driver code in your application." which is what you're doing now. Your software probably won't pass Fedora review that way (bundling library code is very much frowned upon), but since upstream is not willing to support that API as a public API, it's either that or not using that API at all.