| Summary: | krita-3.1.4-x86_64.appimage fails to run with 'could not find or load the Qt platform plugin "xcb"' | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Sean Bolton <sean> |
| Component: | Instant Preview | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | camille, cpel, halla |
| Priority: | NOR | ||
| Version: | 3.1.4 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Sean Bolton
2017-07-31 06:36:20 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. I just confirmed that this same problem occurs with krita-3.2.0-x86_64.appimage but libqxcb.so doesn't directly link to any png library... It must load something that does link to libpng, though. Problem still persists as of 3.2.1 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. (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. 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.
Installing libpng-devel will also install libpng, it's a transitive dependency. (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. I make the appimages with that script... (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. 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. (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. 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! Okay, thank you 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 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. 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! Good! 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 |