Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Installation and Deployment
  4. Qt application is a 'QApplication' / not respecting qt.conf
Qt 6.11 is out! See what's new in the release blog

Qt application is a 'QApplication' / not respecting qt.conf

Scheduled Pinned Locked Moved Installation and Deployment
qt.conf qapplic
7 Posts 3 Posters 3.0k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    S. Carney
    wrote on last edited by
    #1

    We are deploying two different Qt applications via rpm. One is a QGuiApplication and the other is a QApplication.

    We are using Qt version 5.4.1 on RHEL7( v.7.1 ).

    We are deploying a qt.conf alongside the Qt Application binary. It has a [Paths] groups followed by a Prefix = /path/to/Qt/Installation.

    When we turn on QT_DEBUG_PLUGINS, the application that is a QGuiApplication is respecting the settings in qt.conf while the application that is a QApplication is not. When I looked through the Qt code, I thought that a QApplication is derived from a QGuiApplication which, in turn, is a subclass of QCoreApplication. Shouldn't an application of class QApplication respect the settings in qt.conf?

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi and welcome to devnet,

      Indeed QApplication should also respect qt.conf

      Can you show the content of both your qt.conf files ?

      Can you reproduce that with a minimal application ?

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • S Offline
        S Offline
        S. Carney
        wrote on last edited by
        #3

        Maybe I figured it out. For the application that does work with qt.conf, the QT entry in its .pro file is
        QT += core gui network xml widgets sql opengl quick qml

        For the application that doesn't work with the qt.conf file, it's .pro file as the following QT entry:
        QT += qml quick sql widgets

        The qt.conf looks like:

        [Paths]
        Prefix = /opt/qt/Qt-5.4.1
        
        1 Reply Last reply
        0
        • S Offline
          S Offline
          S. Carney
          wrote on last edited by
          #4

          Well I have been at trying to create a scaled down app. Here is what I think I know:

          • The main application is declared as a QApplication
          • The main.cpp is instantiating three objects -- all of type QObject.
          • One of these objects is our DatabaseMgr object and it is trying to connect to an SQLite database.
          • With the QT_DEBUG_PLUGINS environment variable set to 1, we see
          QSqlDatabase: available drivers: 
          QSqlDatabase: an instance of QCoreApplication is required for loading driver plugins
          QSqlDatabase: QSQLITE driver not loaded
          QSqlDatabase: available drivers: 
          QSqlDatabase: an instance of QCoreApplication is required for loading driver plugins
          QSqlDatabase: QSQLITE driver not loaded
          QSqlDatabase: available drivers: 
          QSqlDatabase: an instance of QCoreApplication is required for loading driver plugins
          This application failed to start because it could not find or load the Qt platform plugin "xcb".```
          
          Is the problem that those three objects are all instantiated as *QObject* and that is why *qt.conf* is not respected?
          1 Reply Last reply
          0
          • hskoglundH Offline
            hskoglundH Offline
            hskoglund
            wrote on last edited by
            #5

            Hi, in your main.cpp, if you're instantiating your objects before doing
            QApplication a(argc, argv); then maybe you're bitten by this bug:
            https://bugreports.qt.io/browse/QTBUG-38598

            One workaround is to use addLibraryPath() instead of a qt.conf (or reorder the instantiating of the objects). Good news (for Xmas) is that this bug is fixed in Qt 5.6.

            1 Reply Last reply
            0
            • S Offline
              S Offline
              S. Carney
              wrote on last edited by
              #6

              I think hskoglund gave us what we needed. Basically, it boiled down to reordering instantiation of the objects. That fixed the problem.

              Thanx much for everybody's help.

              1 Reply Last reply
              0
              • S Offline
                S Offline
                S. Carney
                wrote on last edited by
                #7

                All,

                A colleague pointed out:

                I don't think Qt 5.6 would have helped in this case. The root cause was that the source code was referencing a plugin before the qt.conf file was loaded. The loading of the qt.conf file is what has been set up to tell the application where to find the Qt libraries. Since the qt.conf file was not loaded yet, it was unable to determine where the plugin was and erred out. This would still be the case even with a newer version of Qt.

                Is that true? Does Qt 5.6 address this issue?

                1 Reply Last reply
                0

                • Login

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Users
                • Groups
                • Search
                • Get Qt Extensions
                • Unsolved