Bug 382944 - krita-3.1.4-x86_64.appimage fails to run with 'could not find or load the Qt platform plugin "xcb"'
Summary: krita-3.1.4-x86_64.appimage fails to run with 'could not find or load the Qt ...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Instant Preview (show other bugs)
Version: 3.1.4
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-31 06:36 UTC by Sean Bolton
Modified: 2018-03-27 22:50 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Bolton 2017-07-31 06:36:20 UTC
Attempting to run krita-3.1.4-x86_64.appimage on my Slackware 14.2-current x86_64 system fails with:

```
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Available platform plugins are: minimal, offscreen, xcb.

Reinstalling the application may fix this problem.
Aborted
```

Running 'QT_DEBUG_PLUGINS=1 ./krita-3.1.4-x86_64.appimage' reveals the following:

```
QLibraryPrivate::loadPlugin failed on "/tmp/.mount_LTAl95/usr/bin/plugins/platforms/libqxcb.so" : "Cannot load library /tmp/.mount_LTAl95/usr/bin/plugins/platforms/libqxcb.so: (./lib/libz.so.1: version `ZLIB_1.2.9' not found (required by /usr/lib64/libpng16.so.16))"
```

So the problem is that libqxcb.so (which is contained in the AppImage) links to libpng16.so.16 (which is *not* in the AppImage), which links to libz.so.1 (which *is* in the AppImage).

I am not familiar with AppImage, but I am surprised it does not contain some sort of automated check in the build process, to prevent just this situation where linked-to libraries outside the AppImage link to libraries that can be found inside the AppImage. The in-out-in linkage situation is an open door to this sort of version mismatch.

The fix would be to include libpng16.so.16 in the AppImage. A workaround on my system is to link to an older version of libpng16.so.16:

```
mkdir /home/smbolton/t
ln -s /usr/lib64/libpng16.so.16.27.0 /home/smbolton/t/libpng16.so.16
LD_LIBRARY_PATH=/home/smbolton/t ./krita-3.1.4-x86_64.appimage
```

Thanks!
Comment 1 Camille Scholtz 2017-08-22 13:07:51 UTC
I'm running into the same issue, and I can confirm that libpng.so is the offending library. By downgrading my system libpng from 1.16.31 to 1.16.27 I am able to launch the Krita AppImage.
Comment 2 Sean Bolton 2017-08-23 22:43:58 UTC
I just confirmed that this same problem occurs with krita-3.2.0-x86_64.appimage
Comment 3 Halla Rempt 2017-08-24 13:56:34 UTC
but libqxcb.so doesn't directly link to any png library... It must load something that does link to libpng, though.
Comment 4 cpel 2017-09-10 20:07:58 UTC
Problem still persists as of 3.2.1
Comment 5 Halla Rempt 2017-09-10 21:04:05 UTC
Of course it does. I haven't made any changes to the way I create the appimages, and I won't until someone figures out this issue and tells me how to fix it.
Comment 6 cpel 2017-09-10 21:26:43 UTC
(In reply to Boudewijn Rempt from comment #5)
> Of course it does. I haven't made any changes to the way I create the
> appimages, and I won't until someone figures out this issue and tells me how
> to fix it.

https://github.com/KDE/krita/blob/master/packaging/linux/appimage/build-deps.sh#L43

Observation: Only libpng-devel is included as a dependency, not libpng itself.
Comment 7 cpel 2017-09-17 01:26:36 UTC
Running `build-deps.sh` in a Centos 6.9 VM, get this:

> libpng16.so.16.23.0: undefined reference to `inflateReset2`

...which is a part of ZLib. I don't see why there is a compilation problem, I am building from the krita/3.3 branch, and the only environment difference is the use of Centos 6.9 rather than 6.8. which is what the README.txt has listed.

I might try installing Docker rather than using a VM.
Comment 8 Halla Rempt 2017-11-27 08:43:43 UTC
Installing libpng-devel will also install libpng, it's a transitive dependency.
Comment 9 cpel 2017-11-27 19:22:17 UTC
(In reply to Boudewijn Rempt from comment #8)
> Installing libpng-devel will also install libpng, it's a transitive
> dependency.

I could not get the build script provided by the Krita git working; I couldn't find a single working packaging script elsewhere. I'm curious as to how the Krita team generates its Appimages, cause it seems like a mess at the moment.

I feel like KDE needs a standardized Appimage packager, like Electron provides.
Comment 10 Halla Rempt 2017-11-27 19:25:43 UTC
I make the appimages with that script...
Comment 11 cpel 2017-11-27 19:37:01 UTC
(In reply to Boudewijn Rempt from comment #10)
> I make the appimages with that script...

It's the dependencies script which doesn't work, not the actual build script. Sorry, I should have been more specific.
Comment 12 Halla Rempt 2017-11-27 20:02:24 UTC
Well, it worked when I setup my centos vm -- I could give it another try and see whether something has changed, but I am supposed to spend all my time on the text tool first.
Comment 13 cpel 2017-11-27 20:20:15 UTC
(In reply to Boudewijn Rempt from comment #12)
> Well, it worked when I setup my centos vm -- I could give it another try and
> see whether something has changed, but I am supposed to spend all my time on
> the text tool first.

If I may, I would like to contribute to Appimage packaging for KDE in general. I don't know if any KDE applications other than Krita and KDevelop are distributing Appimages, but creating a standard tool which bundles KF libs and Qt would benefit application distribution in the long run.
Comment 14 Halla Rempt 2017-11-27 21:02:11 UTC
Of course you may :-). You probably should start hanging out on #kde-devel and #appimage on irc.freenode.org if you want to do that!
Comment 15 cpel 2017-11-27 21:26:46 UTC
Okay, thank you
Comment 16 Sean Bolton 2017-11-27 22:02:46 UTC
I'm sure this is no surprise, but the krita-3.3.2-x86_64.appimage still fails to work on my Slackware 14.2-current system, failing for the exact same reason.

If the libpng package is being installed as a dependency of libpng-devel, why does libpng16.so.16 not get included in the AppImage? Is it maybe because libpng12.so.2 is included, and the build script thinks that satisfies the need for libpng16?

@cpel, if you do pursue this standard AppImage build tool, you might look at how the pax-utils 'lddtree' [1] tool scans for library dependencies, which could relieve the packager of the necessity of listing the dependencies by hand.

[1] https://github.com/gentoo/pax-utils
Comment 17 Halla Rempt 2018-03-27 08:18:55 UTC
Please try again with the 4.0 appimage. Also check whether slackware sets the QT_PLUGIN_PATH variable by default. If so, unset it and complain to the slackware maintainers, because that variable should not be set.
Comment 18 Sean Bolton 2018-03-27 14:54:01 UTC
Yes, the krita-4.0.0-x86_64.appimage is working on my Slackware 14.2-current system. Checking carefully with ldd, I see none of the 'in-AppImage, out-of-AppImage, in-AppImage' linkage that resulted in the previous breakage.

Slackware does not set QT_PLUGIN_PATH.

Thank you!
Comment 19 Halla Rempt 2018-03-27 15:40:59 UTC
Good!
Comment 20 cpel 2018-03-27 22:50:16 UTC
Glad this issue is resolved. As a shameless plug, I have been working on a small tool for organizing files to be bundled with an Appimage.

Perhaps if any issues come up in the future: https://github.com/ChrootDoot/Appimage-Deptree