Inconsistency between Qt5 parts in AppImage and client

I create - for some time now - AppImages for Qt-DAB and some other programs using Ubuntu 16. When trying to go “up” to Ubuntu 18, the AppImage can be built, no problem, although when executing it in my “work” environment (either U20 or fedora 35-37) The AppImage fails with the message

"tmp/.mount_Qt_DABkjsRYP/usr/bin/qt-dab-5: /lib64/ no version information available (required by /tmp/.mount_Qt_DABkjsRYP/usr/bin/qt-dab-5)
qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb."

Of course xcb is available on my platform

Any idea how to address this ?

I will hazard two guesses.

  1. You never tested your AppImage on a platform that didn’t have Qt pre-installed.
  2. It was never packaged “quite right.” This kind of goes hand-in-hand with 1.

I gave up on Qt being a stable, viable development tool quite some time ago. The definition of what is OpenSource shrinks by the nanosecond with Qt Company and the library is rife with compatibility issues between versions.

I’ve moved to CopperSpice which is a fork of the last OpenSource version of Qt, 4.8. It also has many changes and improvements. Most importantly it is not yet pre-installed on most Linux platforms so I miss very little. I just finished (yesterday) testing on all platforms a new release of my RedDiamond editor which has an AppImage.

I work from the .deb files I create for other projects. In the code tab you want to look at appimage-instructions.txt. and appimage-3-5-9.json. I have not yet updated the wiki for build instructions. You can get the two -dev -devel packages needed to build this one from here:

Pay particular attention to the comments and code at the top of main.cpp

You also need to pay extremely close attention to the postrun section of appimage-3-5-9.json

I went through a lot of pain identifying every file that was an external dependency for CopperSpice (which should be pretty close to your era Qt)

The mv statement is absolutely critical!

Almost every AppImage creator puts their binary in /usr/bin. Neither Qt nor CopperSpice will look in AppDir/usr/lib for their plugins. You have to hack your build specifically for AppImage adding a library path that exists within the AppImage as it is seen by the outside world or you munge your package like I did. By default both will look for the plugin directories at the same level as the binary, hence the mv statement.

So, without running your AppImage, here’s most likely what happened in order of probability.

  1. The plugin directory wasn’t where your binary wanted so it found the system installed Qt plugin directory. That was in the lib64 path on Fedora (whatever RPM distro) and the newer stuff wanted things that weren’t installed.

  2. You didn’t run ldd on your executable and all of its plugins prior to creating your package. This means you missed something, most likely a networking thing since your current package is gagging on curl. On Manjaro the current libcurl stuff is

Given the advanced age (Ubuntu 12) that you are porting up from I highly recommend you just jump ship to CopperSpice and thieve my AppImage stuff for RedDiamond. Qt is being abandoned by most embedded systems shops that I know of due to its can-o-worms licensing and open bug database of something like 22K right now.

Ooops! My bad! 30K

If you insist on sticking with Qt which is declining, then you have to ldd your binary where you built it for packaging. You then have to ldd every plugin you are going to bundle with it. Put the plugins in the directory where your bundled binary will look for them. Compare list of required libraries to list of things “assumed” to be in AppImage package and cp in all those items not on that list.

Note: You really need to ldd every library because, infuriatingly, many libraries require other libraries.

Not completely true, for years I made AppImages of the application first on U12, then from Ubuntu 16, but since

U16 is about 7 years old I started to build on U18, with the result as reported.
Qt-DAB is - as the name suggests a piece of SDR software for DAB decoding (DAB=Digital Audio Broadcasting),

it supports a vriety of input devices and to show attributes of the signal, the attributes of the decoding etc source files

(cpp and include files) it takes well over 50000 lines of code.
With mingw64 I cross compile for windows as well.

The U16 builds ran - and runs - without any problem on Linux boxes without C compilers, and all libs needed for
Qt were always included in the AppImage, so to me it seems that the linuxdeployqt program is not aware of all required libraries

and plugins for running Qt