A missing Qt5 dxcb plugin: the original dependency investigation

Original publication: 2025-07-30. English edition and practical reading notes: Linglong editorial, 18 October 2026. Chinese original.

The 30 July 2025 article credited MeGusta and reproduced a community forum investigation. It concerned a Qt5 application that could not find the dxcb platform plugin.

The reported procedure

First, the author downloaded six DEB packages from the repository:

apt download libxcb-damage0 libxcb-composite0 libqt5xdg3 libqt5xdgiconloader3 dde-qt5integration dde-qt5xcb-plugin

After extracting them, the author collected and arranged the files shown in the original image.

Before starting the example application, scdtool.bin, the author added the following plugin search paths:

export QT_PLUGIN_PATH="$QT_PLUGIN_PATH:/opt/apps/${LINGLONG_APPID}/files/lib/x86_64-linux-gnu/qt5/plugins"
export QT_QPA_PLATFORM_PLUGIN_PATH="$QT_QPA_PLATFORM_PLUGIN_PATH:/opt/apps/${LINGLONG_APPID}/files/lib/x86_64-linux-gnu/qt5/plugins/platforms"

For another base/runtime combination, the article recommended inspecting the dynamic-library dependencies individually if the change did not work. For Qt5 packages built with Linglong Killer, it suggested adding those packages to deps.list to obtain DDE-style file dialogs and window decoration.

Why the first library fix was insufficient

The author described a default QT_QPA_PLATFORM=dxcb;xcb in the deepin/Linyaps environment: Qt5 first tried DDE’s dxcb style, then could fall back to Qt’s xcb style when the required components were incomplete.

libdxcb.so came from dde-qt5xcb-plugin. The author had already used ldd libdxcb.so | grep not to fill missing dependencies, but that alone did not solve the problem. Comparing package.list for org.deepin.Runtime/23.0.1.4 suggested that dde-qt5integration was also missing. Adding dependencies, setting the Qt paths and rebuilding produced the reported result.

The original style comparison

The article contrasted the default Qt5 xcb appearance with the DDE dxcb appearance in the following screenshots. These are the original author’s screenshots, not a new test of the current runtime.

Use the investigation, not an unqualified fix

The path in the example is explicitly x86_64 and the runtime is a 2025 case. Do not paste it into an unrelated architecture or replace a current runtime with old libraries.

1. Keep the exact Qt error and the application/runtime versions.
2. Check whether the required plugin file exists at the path used by that application.
3. Inspect dependencies only for artifacts you trust; keep the plugin itself separate from the libraries it requires.
4. Compare a known working package list, then change one dependency or path at a time in a test environment.
5. Record both a usable window and the expected file dialog/decoration. A different style is not automatically a failed launch.