Installation and Deployment

Hi, Checking !installer.isInstaller() should be enough for determining that the current application is a Maintenance Tool. The installer.isInstaller() and related methods installer.isPackageManager(), installer.isUpdater(), and installer.isUninstaller() all determine their return value based on a single internal property that describes the current run mode of the application. Those methods are used quite extensively in the official Qt packages' installation scripts, so installer.isInstaller() returning true also for the Maintenance Tool sounds unexpected. Could you share a minimal install script example that reproduces the issue you are encountering?

@Malachi said in The required XCB cursor platform library was not found! Please use your distribution's package manager to install it.: I've been bonking into this error (warning?) for years. Are there no suggestions how to repair it? The error message tells you how to repair it: By installing the XCB cursor library. sudo apt install libxcb-cursor0

@Malachi said in The required XCB cursor platform library was not found!: I've been bonking into this error (warning?) for years. Are there no suggestions how to repair it? Do you mean the warning about XCB cursor being not found? The solution is to install the missing library. On Ubuntu 22.04, you want sudo apt install libxcb-cursor0

@JKSH I've made some progress - merged my changes from QtSvg 6.10 into 6.12. Also tried rebase (on a separate copy), but rebasing is a separate sorcery skill I clearly do not possess at the moment. The merged version builds, but my CMakeUserPresets got lost somewhere in the merging, and now Qt Creator builds everything in the repo/build directory. A minor inconvenience, but tolerable. Running tests and examples against the new build (and ensuring they are run against the new build) needs more time. I remember trying my previous CMake build with a custom LD_LIBRARY_PATH to ensure it uses the right stuff. Maybe it will be applicable in this case as well. Qt Creator likely has env variables somewhere in the Project settings, haven't explored those yet. The AI that I poke with different stupid questions also suggests that I can try ldd /path/to/your/example | grep Svg to verify that the example/test will use the correct library before running it. I'll circle back to this thread when I have more info to share.

The problem is that you defined QT_BUILD_STANDALONE_TESTS (which expects an installed module) instead of QT_BUILD_TESTS (which builds tests in the same tree as the module you are building) — just replace it with the correct variable and rebuild. Fix in CMakeUserPresets.json "QT_BUILD_EXAMPLES": "OFF", "QT_BUILD_STANDALONE_EXAMPLES": "OFF", "QT_BUILD_TESTS": "ON"

Suspected cause The problem appears to be caused by this code in Qt Android accessibility: QJniObject rangeInfo( "android/view/accessibility/AccessibilityNodeInfo$RangeInfo", "(IFFF)V", rangeType, min, max, current); The constructor signature "(IFFF)V" is not available on Android 10 runtime. The call creates a pending JNI exception: java.lang.NoSuchMethodError but the exception is not cleared before continuing, which results in SIGABRT. Proposed fix The RangeInfo constructor usage should be protected by Android API level check. For example: if (QtAndroidPrivate::androidSdkVersion() >= 36) { QJniObject rangeInfo( "android/view/accessibility/AccessibilityNodeInfo$RangeInfo", "(IFFF)V", rangeType, min, max, current); if (rangeInfo.isValid()) env->CallVoidMethod(node, m_setRangeInfoMethodID, rangeInfo.object()); } or alternatively Qt should use the correct API availability check for RangeInfo constructor.

Hi, With which compiler ? Which configure parameters did you use ? What number of cores are you using at the same time ? What are your machine specifications ?

@Taytoo said in Are CVE patches pre-applied to the sources of older versions as well?: if I download the latest sources of the affected version (e.g. 5.15.19). Would they have the CVE patches applied already? No, the sources of Qt 5.15.19 remain exactly as how they were released back in May 2025 (https://www.qt.io/blog/commercial-lts-qt-5.15.19-released ). You'll need to apply the patches manually or upgrade to a version that already contains the patch.

Then I would check the cmake bug tracker to see if there's something related there.

I edited socketcanbackend.cpp to include the missing include file (<linux/sockios.h>) and compiling is proceding...

I want to complete toolchain qt creator cross compile for ARM_64 my host is x86_64 and cross compile for ARM_64 khadas bord.

Hi and welcome to devnet, Which version of the Maintenance tool do you have ?

I figured it out... Thanks... It was just a syntax problem...

@flashmozzg Hi, unfortunately you need to do a fresh install. We'll look into improving this particular case.

That's a generated script in the build folder. It's called automatically for you. If you want to see its content, there are hidden folders in the build folder.

@Poornesh said in Patch Application Failure on Yocto Zeus + Qt 5.15 Due to Source Revision Mismatch: Dear Qt Support Team Please be aware this forum is for users of Qt. It is not read by The Qt Company. My limited understanding is that Qt for Yocto is part of "Boot to Qt" (https://doc.qt.io/Boot2Qt/b2qt-customization-requirements.html)? If that is true I believe this means you must have a commercial license for The Qt Company? And if that is so then, although you are welcome to post here and await any user answers which might come, you may have to contact TQtC for your issue?

@MSDev said in Disclosure of Application Source Code under LGPL v3.0: So if I do dynamic linking then I don't have to share my source codes right? In addition to what my colleagues have said. Since your code is in PySide/Python rather than C++, how do you propose not to "share your source code" anyway? Unlike the C++ situation your Python files are required at runtime and are perfectly readable to anyone. Unless you do some sort of "obfuscation" or you can force somehow to compile the Python you won't be supplying any "object" files of your own anyway?

Hi, Glad you found out and thanks for sharing the solution ! You can close the thread yourself by using the Topic Tools button or the three dotted menu beside the answer you deem correct :-)