Cannot run kdenlive AppImage 25.08.x on Fedora 42/43

Help
1

I’m unable to run kdenlive from the 25.08.x AppImage. Here’s what I’m getting:

$ ./kdenlive-25.08.2-x86_64.AppImage
/tmp/.mount_kdenliFmOMpe/AppRun.wrapped: /tmp/.mount_kdenliFmOMpe/usr/bin/../lib/libcrypto.so.3: version `OPENSSL_3.0.1’ not found (required by /lib64/libssl.so.3)

I tried setting LD_LIBRARY_PATH, but that didn’t help:

$ LD_LIBRARY_PATH=/usr/lib64 ./kdenlive-25.08.2-x86_64.AppImage
qt.qpa.plugin: Could not find the Qt platform plugin “xcb” in “”
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Aborted (core dumped) LD_LIBRARY_PATH=/usr/lib64 ./kdenlive-25.08.2-x86_64.AppImage

I even tried setting QT_QPA_PLATFORM_PLUGIN_PATH, but that was even worse!

$ QT_QPA_PLATFORM_PLUGIN_PATH=/usr/lib64/qt6/plugins/platforms LD_LIBRARY_PATH=/usr/lib64 ./kdenlive-25.08.2-x86_64.AppImage
qt.accessibility.atspi: Error in contacting registry: “org.freedesktop.DBus.Error.Spawn.ExecFailed” “Failed to execute program org.a11y.atspi.Registry: Permission denied”
kf.notifications: Failed to play sound with canberra: File or data not found
mlt_repository_init: failed to dlopen /tmp/.mount_kdenliLKLKKf/usr/lib/mlt-7/libmltspatialaudio.so
(/tmp/.mount_kdenliLKLKKf/usr/lib/mlt-7/libmltspatialaudio.so: undefined symbol: _ZN22CAmbisonicBinauralizer7ProcessEP8CBFormatPPfj)
profilePath from $MLT_PROFILES_PATH: “/tmp/.mount_kdenliLKLKKf/usr/share/mlt-7/profiles/”
meltPath from KdenliveSetting::meltPath: “/tmp/.mount_kdenliLKLKKf/usr/bin/melt”
Starting render server
Empty metadata for “glsl.manager”
kf.i18n: Trying to convert empty KLocalizedString to QString.
Empty metadata for “telecide”
qt.core.qobject.connect: QObject::connect: signal not found in Core
No QtMultimedia backends found. Only QMediaDevices, QAudioDevice, QSoundEffect, QAudioSink, and QAudioSource are available.
qrc:/qt/qml/org/kde/kdenlive/ClipMonitor.qml:6:1: Cannot load library /tmp/.mount_kdenliLKLKKf/usr/qml/QtQuick/Controls/libqtquickcontrols2plugin.so: /usr/lib64/libQt6QuickControls2.so.6: version `Qt_6_PRIVATE_API’ not found (required by /tmp/.mount_kdenliLKLKKf/usr/qml/QtQuick/Controls/libqtquickcontrols2plugin.so)
import QtQuick.Controls 2.15
^
Segmentation fault (core dumped) QT_QPA_PLATFORM_PLUGIN_PATH=/usr/lib64/qt6/plugins/platforms LD_LIBRARY_PATH=/usr/lib64 ./kdenlive-25.08.2-x86_64.AppImage

I removed all traces of qt5 that I could, to see if that would help:

$ rpm -qa | grep -i qt | grep -v qt6
qt5-srpm-macros-5.15.17-2.fc43.noarch
kf6-networkmanager-qt-6.19.0-1.fc43.x86_64
PyQt-builder-1.19.0-1.fc43.noarch
PyQt4-doc-4.12.3-51.fc43.noarch

Still no go. This doesn’t happen with kdenlive AppImage 25.04.3 or older. It’s a new problem for me with 25.08. I’ve just upgraded my Fedora to 43, but this was also happening in Fedora 42.

Is there some dependency that I’m missing?

Thanks.

2

Only a compatible base distro it would seem …

I tried setting LD_LIBRARY_PATH, but that didn’t help:
I even tried setting QT_QPA_PLATFORM_PLUGIN_PATH, but that was even worse!

Yeah, that’s not surprising, because it’s trying to ‘fix’ the problem in the wrong direction.
Your problem isn’t that it can’t find something on your system, it’s that it’s somehow pulling in things from the system that it shouldn’t be.

But it’s a curious one, and not clear to me yet why it should be doing that.

OPENSSL_3.0.1 looks like a fedora-specific symbol version from some point-release build of their own - either because their build system for it is borked or they’ve actually backported new interfaces from a later release. But that still shouldn’t be a problem for us because we should never be touching /lib64/libssl.so.3, it should be using the copy of that shipped in the AppImage.

This doesn’t happen with kdenlive AppImage 25.04.3 or older.

I think that coincides with KDE’s latest update of their Craft build farm, which occasionally busts things for people on some older distro releases by requiring newer libc symbols or the like - but this is a bit different to that, and it wasn’t just a distro upgrade this time, they switched it over to a different base distro - and there have been few teething issues as a result of that.

But it still doesn’t easily explain what you’re seeing to me yet either.

The only change to external dependencies (system libs we don’t ship in the AppImage) between 25.04.3 and 25.08.2 appears to be the addition of libcom_err.so.2 - but it shouldn’t depend on libssl (or much more than just libc really), so it’s not on my short-list of Most Likely Culprits.

And the only external dependencies for 25.08.2 should be:

    linux-vdso.so.1 (0x00007ff6dac29000)
    libOpenGL.so.0 => /lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007ff6d992e000)
    libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007ff6d98fa000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff6d9742000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff6d3000000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff6d7e29000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff6d88ef000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff6d947f000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff6d2e0a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff6dac2b000)
    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff6d3eb8000)
    libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007ff6d6ec8000)
    libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff6d596c000)
    libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007ff6d3b47000)
    libEGL.so.1 => /lib/x86_64-linux-gnu/libEGL.so.1 (0x00007ff6d593f000)
    libdrm.so.2 => /lib/x86_64-linux-gnu/libdrm.so.2 (0x00007ff6d4701000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007ff6d3e4f000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff6d3e3e000)
    libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007ff6d326c000)
    libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff6d3267000)
    libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ff6d2c63000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007ff6d2c51000)

So my first guess based on what you’ve told us has to be that one of those on fedora is also trying to pull in openssl libs and you’ve got two different versions of it crashing into each other head on.

But it’s probably going to need someone with a fedora system to do more digging to say much more than that.

fwiw, fedora has historically been among the more troublesome distros that people report problems with here, both for it’s own packaged versions and running the ‘official’ self-contained images - but I’m not seeing anything obviously different between 25.04 and 25.08 to explain what’s triggered what you are seeing, and you are the first to report this here.

Unless it’s something else you’ve also got installed on the same machine that’s overriding library search paths or system libs?

3

Thank you for the information and analysis. It was very helpful in tracking down the problem. What I deduced is that the AppImage is looking for libavformat.so.61 (rather than just libavformat.so). I’ve been building ffmpeg for a long time (no special custom code, I just have some plugins that I like), so my /usr/local/lib is littered with older versions.

lrwxrwxrwx. 1 23 Sep 15 16:42 libavformat.so → libavformat.so.62.5.100
lrwxrwxrwx. 1 23 Mar 24 2025 libavformat.so.61 → libavformat.so.61.9.107
-rwxr-xr-x. 1 2824728 Mar 24 2025 libavformat.so.61.9.107
lrwxrwxrwx. 1 23 Sep 15 16:42 libavformat.so.62 → libavformat.so.62.5.100
-rwxr-xr-x. 1 2911216 Jul 7 09:13 libavformat.so.62.1.101
-rwxr-xr-x. 1 2972816 Sep 15 16:42 libavformat.so.62.5.100

If I remove the libavformat.so.61 link, orphan it by removing libavformat.so.61.9.107, or even remove all libavformat files from /usr/local/lib, kdenlive runs.

FWIW, here’s what’s in /usr/lib64. I’m explicitly setting LD_LIBRARY_PATH=/usr/local/lib for these tests, though.

3277603 0 lrwxrwxrwx 1 root root 23 Oct 3 20:00 /usr/lib64/libavformat.so.61 → libavformat.so.61.7.100
3321031 0 lrwxrwxrwx 1 root root 23 Oct 3 20:00 /usr/lib64/libavformat.so → libavformat.so.61.7.100
3317703 0 lrwxrwxrwx 1 root root 24 Sep 15 20:00 /usr/lib64/libavformat.so.58 → libavformat.so.58.76.100
3277606 2572 -rwxr-xr-x 1 root root 2632032 Oct 3 20:00 /usr/lib64/libavformat.so.61.7.100
3317704 2344 -rwxr-xr-x 1 root root 2398536 Sep 15 20:00 /usr/lib64/libavformat.so.58.76.100

I don’t think I’ve got anything that really needs my local version of libavformat.so.61, since ffmpeg is building version 62 now, so removing it is an acceptable fix for me.

1 Like
4

Yeah, it can’t do the latter at runtime. It does that at build time to decide what version to build with, but the versioned soname is there to ensure binary compatibility.

Usually this means you can have multiple versions installed in parallel just fine, that’s what sonames were designed to do - but the problem case occurs when you have something like app1 linking to liba.1 and libb.1 but the liba.1 on the runtime system also itself links to libb.2 - so app1 tries to pull in both libb.1 and libb.2, then symbols collide, cats and dogs living in sin etc. etc.

libav is kind of notorious for this because so many possible dependencies link to it, and plugins can make this equation even more complex.

I’ve been burned by trying to have local apps built with a newer libav before too, and the bugs can get really weird and subtle, much more than this. You can get away with it for long enough to think you’re ok, and then Impossible things will start to happen long after you’ve forgotten it was there.

Really the only sane way to have a different libav is to rebuild everything on your system with the one you want.

The core idea of the appimage is to encapsulate that, so you can have a little walled garden using the libav et al. that you tested your app with rather than whatever version the local system is using, so it will run on more systems than it otherwise might - but it doesn’t try to reset things like LD_LIBRARY_PATH, and probably it shouldn’t, it should be up to the runtime system and its user how and where the external dependencies are found, and we don’t want to contaminate external system binaries with the libs we ship - but that does mean if you override that, you need to be careful and get to keep all the pieces if you get it wrong. One of the ‘advantages’ of the AppImage over flatpak is that it doesn’t pretend to ‘sandbox’ the application - it should be able to use system resources in the same way as if it was a ‘natively’ packaged app.

Anyway, I’m glad you figured it out without too much more pain, and thanks for coming back here to share what you found!