Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-95713 Post-Qt-6.2.0 release CMake API follow ups
  3. QTBUG-95149

Fix use case of linking an executable to a shared library QML module backing target

    XMLWordPrintable

Details

    Description

      Context
      https://git.qt.io/alcroito/qt6-cmake-api-review/-/commit/14b4999bc857f5402a3577fe334ebfb3602ad0c2#f3ff9c1b48af14adf093e2af0c5cf2849829bb6d_176_236

      Currently if a user executable directly links to a shared library QML backing target and doesn't deploy the associated shared qml plugin, if the executable has no references to symbols in the shared library, the linker might decide not to add a dependency on the shared library at all. As a result the qml module will not be found at run time.

      The current work around for that is to ensure deployment of the plugins and qmldir files, so that the qml engine can load those.

      We could try to fix this issue by creating an object library with a global constructor that references the qml type registration function of the backing library.

      This object library would then have to be linked to the executable along with the shared backing library. This would ensure the backing library is not discarded by the linker. This would require CMake 3.21 though, for proper object library propagation.

      In some ways this is similar to the Q_IMPORT_PLUGIN object library approach we use for static Qt builds.

      Attachments

        Issue Links

          For Gerrit Dashboard: QTBUG-95149
          # Subject Branch Project Status CR V

          Activity

            People

              fabiankosmale Fabian Kosmale
              alexandru.croitor Alexandru Croitor
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There is 1 open Gerrit change