Details
-
Technical task
-
Resolution: Unresolved
-
P2: Important
-
None
Description
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
- is duplicated by
-
QTBUG-100655 QML module created with the new QML CMake API does not get automatically loaded on Windows when main.qml locates in the created module
- Closed
-
QTBUG-122716 Inconsistent static linking of CMake-defined QML modules
- Closed
- relates to
-
QTBUG-97816 Prevent linker from discarding unused shared libraries
- Reported
-
QTBUG-128568 [REG Qt 6.7.0-> 6.8.0 beta4] QML module linked as library doesn't work anymore
- Closed
-
QTBUG-123333 qt_add_qml_module with NO_PLUGIN can fail to load when using as-needed linking
- Reported
Gerrit Reviews
For Gerrit Dashboard: QTBUG-95149 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
367149,6 | WIP: use object lib as interface dependency | dev | qt/qtdeclarative | Status: NEW | -2 | 0 |