AppImage not running on Arch Linux

[alex-nitrokey]

I couldn't get the AppImage build (see #286) running on my Arch Linux system.

I did:

$ chmod u+x Nitrokey.App.AppImage
$ ./Nitrokey.App.AppImage
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Available platform plugins are: xcb.

Reinstalling the application may fix this problem.
zsh: abort (core dumped)  ./Nitrokey.App.AppImage

Another user reported that she/he couldn't get it starting as well (more information will hopefully follow). Does anybody know, what could be done to make it usable for even more distributions?

[szszszsz]

Hi!

1. Have you tried the 16.04 build from the beta? v1.3 was built on 14.04.
2. Do you have Qt libraries installed (it should not be required, but this might give some clues)?

[alex-nitrokey]

1. I tried either one. Same results.
2. I have different Qt libraries installed (e.g. qt5-svg), sure. And I think there is something not working well with theses Qt libraries dependencies (especially for the app installed on system), but I still couldn't manage to figure it out (see #232 as well). Maybe it is connected, maybe not at all. Let's see, what system other user is using, as it is surely not Arch Linux...

[szszszsz]

I see. I will check was the proper plugin file copied to the archive.

[alex-nitrokey]

Hyperbola it is... The output reads

Cannot mix incompatible Qt library (version 0x50800) with this library
(version 0x50904)

I guess Hyperbola is even more special, but I thought that is what AppImage is for :thinking: :wink:

[szszszsz]

@probonopd Hi! Any ideas what could be missed and how to debug it? Perhaps I could fix the first case by copying the missing platform plugin, but what about the library mixing? I think the error message mean that App is trying to access some Qt library in the OS, but all libraries were meant to be provided by the AppImage already.

[probonopd]

I could imagine that this causes the issue:

https://github.com/Nitrokey/nitrokey-app.build/blob/1b8b7f18dc1d8bd9d4dbb2a269f5bbb1384f5e37/docker/ubuntu_xenial/_build.sh#L46-L48

Just copying in Qt components (rather than having them deployed by linuxdeployqt) may cause these components to try loading Qt from the system, which leads to incompatible Qt versions being mixed. What happens if you use the -extra-plugins=<list> option instead of the lines above?

Usage examples:

-extra-plugins=sqldrivers/libqmsql.so,iconengines/libqsvgicon.so -extra-plugins=sqldrivers,iconengines/libqsvgicon.so -extra-plugins=sqldrivers,iconengines,mediaservice,gamepads

how to debug it?

Run ldd on every .so in the AppImage and see if it tries to load Qt libraries from the system (/usr/...) rather than the one in the AppImage (/tmp/.mount_...). Running the application with LD_DEBUG=libs may give you this information as well.

[szszszsz]

Thank you for the tips! I will check it. I was sure simple copying would suffice, but I forgot about making it depending on the local libraries with a relative path, and here could be the cause indeed. I guess your deploying tool does it.

[FrostKnight]

Yep, that's the problem. How does one fix without using the aur? More importantly is a fix on the way? I just wondered though, is there a way to disable the library temporarily for using the appimage? Aka, for the nitrokey appimage's library to be used instead?

[probonopd]

Using the -extra-plugins=<list> option instead of the manual copy operations should do the trick. Whenlinuxdeployqt deploys the Qt plugins, it sets the rpath so that they load the bundled rather than system Qt libraries.

[FrostKnight]

Yeah, I don't have that package, but I did try compiling from source which worked to an extent...

When I opened the nitrokey app from source, and plugged in my nitrokey it wasn't detected. Not sure why though. I wonder if it is debian related error... I ask because, my distro uses debian packages. But also, when I used devuan a debian fork, it had the same problems.

And debian stretch I forget if that had some but I am guessing yes.

[FrostKnight]

interesting... I tried sudoing the nitrokey app i compiled from source and it worked. hmm odd though.

[szszszsz]

Hi @FrostKnight ! I have replied on #352.

[FrostKnight]

@szszszsz thank you, I replied just now.

[FrostKnight]

Good news, in 1.3.1, your Nitrokey-App.AppImage works the way it is supposed to. I owe you all my thanks. :)

[szszszsz]

Great! I am glad it works for you! :-)

[alex-nitrokey]

I get the same message as before though :-(

[szszszsz]

I see. Will check then. I have added whole plugins' platform directory via -extra-plugins=<list>. I wonder should I build it on Arch Linux as well.

[jans23]

Arch has version 1.3.1 already in repository. Hence, no need to get AppImage running on Arch - at least not a priority.

[alex-nitrokey]

Well the point of the AppImage is to have a executable that can run on every system without the need of higher privileges or installing on every system. I guess this applies for Arch Linux, too ;-)

There are good reasons to avoid the AUR as well (although the Nitrokey App PKGBUILD is indeed trustworthy so far).

@szszszsz I don't know anything about building AppImages, to be honest. But as far as I understand @FrostKnight it does work on Arch, at least for some users...?! I don't know what's the matter here for my system.

[szszszsz]

@alex-nitrokey Exactly as you said. It should work everywhere in the principle. I had to take after something else now though, especially while workaround in a form of OS package is provided (the latter should be preferred IMO, since it gives automatic updates).

[jans23]

Yes, it would be good to have a perfect AppImage. But we introduced AppImage for distributions where NK App isn't available yet. From this perspective fixing this issue is not a priority.