Skip to content

qt5base: eglfs plugin packaging failure on multiple architectures due to optional KMS support #104

Description

@titobrasolin

Related Pull Request: #72

I'm working on the PR above to add qt5serialport and qt5serialbus packages, but I've encountered a systematic build failure in qt5base related to the eglfs plugin packaging.

The Problem
The qt5base package currently fails to build on every architecture tested in the CI (including x86_64, ARM, MIPS, RISC-V, and PowerPC) during the packaging phase.

The Makefile assumes libQt5EglFsKmsSupport.so is always created when EGLFS is enabled. However, Qt5 treats KMS/DRM support as a conditional feature within the EGLFS plugin. Even when libdrm is available, the internal feature tests for KMS fail during the configuration phase across all targets in the current CI environment. Consequently, the library is not generated, leading to the following error during the install phase:

cp: cannot stat '.../ipkg-install/usr/lib/libQt5EglFsKmsSupport.so*': No such file or directory

Considerations
Since Qt5's feature detection is opportunistic, the set of generated libraries for EGLFS varies depending on the configuration results.

One possible way to address this could be making the installation of these specific components conditional in the Makefile (e.g., using wildcard checks), ensuring the build completes with the available backends.

For example:

define Package/qt5base-plugin-platforms-eglfs/install
    $(if $(wildcard $(PKG_INSTALL_DIR)/usr/lib/libQt5EglFsKmsSupport.so*),$(call Build/Install/Libs,$(1),libQt5EglFsKmsSupport))
    $(call Build/Install/Plugins,$(1),platforms,libqeglfs)
    ...
endef

However, I'm opening this issue to discuss the best approach: should we try to enforce the presence of KMS support for these targets, or should the packaging be made more flexible to accommodate different build outputs?

I would appreciate your feedback on how to best handle these optional Qt5 components within the OpenWrt framework.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions