Never used an AppImage before, but I thought I wanted to try one (»»») when setting up an old RPi I have.
Well, I didn’t work, and throw a lot of errors, prob missing a lot of stuff - so I ended up doing it the old/normal way with dd.
But, it would be nice to know what happen, and what I need to install to (ev) fix it. From searching reading I guess I need an xtra version of gcc installed - but, from all diff numbers in the output…
¯\_(ツ)_/¯
Summary
$ ll
total 33M
-rwxr-xr-x. 1 me me 33M 18 aug 17.39 imager_latest_amd64.AppImage
lrwxrwxrwx. 1 me me 28 25 aug 07.38 RPi_Imager.AppImage -> imager_latest_amd64.AppImage
$ sudo ./RPi_Imager.AppImage
/tmp/.mount_RPi_Imdcelje/usr/bin/rpi-imager: /lib64/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by /tmp/.mount_RPi_Imdcelje/usr/bin/rpi-imager)
/tmp/.mount_RPi_Imdcelje/usr/bin/rpi-imager: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /tmp/.mount_RPi_Imdcelje/usr/bin/rpi-imager)
/tmp/.mount_RPi_Imdcelje/usr/bin/rpi-imager: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /tmp/.mount_RPi_Imdcelje/usr/bin/rpi-imager)
# Cleaned the rest upp a little to make it easier to read
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.33' not found
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.29' not found (req by libQt6Quick.so.6)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.35' not found (req by libQt6Quick.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found (req by libQt6Quick.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.26' not found (req by libQt6Quick.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.29' not found (req by libQt6Quick.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6Quick.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.28' not found (req by libQt6Quick.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.33' not found (req by libgnutls.so.30)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libgnutls.so.30)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.29' not found (req by libQt6Qml.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found (req by libQt6Qml.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libQt6Qml.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.29' not found (req by libQt6Qml.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6Qml.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found (req by libQt6Network.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libQt6Network.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.26' not found (req by libQt6Network.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.29' not found (req by libQt6Network.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.28' not found (req by libQt6Network.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6Network.so.6)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.35' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.29' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libgcc_s.so.1: v `GCC_12.0.0' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.26' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.29' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.28' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6Gui.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6DBus.so.6)
[…]/rpi-imager: /lib64/libgcc_s.so.1: v `GCC_12.0.0' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.29' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.35' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.28' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.29' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.26' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `CXXABI_1.3.13' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.33' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libQt6Core.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6QmlMeta.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.29' not found (req by libQt6QmlModels.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6QmlModels.so.6)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.35' not found (req by libQt6OpenGL.so.6)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.29' not found (req by libQt6OpenGL.so.6)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6OpenGL.so.6)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.33' not found (req by libp11-kit.so.0)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libp11-kit.so.0)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found (req by libunistring.so.2)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libunistring.so.2)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libzstd.so.1)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.33' not found (req by libglib-2.0.so.0)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.32' not found (req by libglib-2.0.so.0)
[…]/rpi-imager: /lib64/libc.so.6: v `GLIBC_2.34' not found (req by libglib-2.0.so.0)
[…]/rpi-imager: /lib64/libm.so.6: v `GLIBC_2.29' not found (req by libpng16.so.16)
[…]/rpi-imager: /lib64/libstdc++.so.6: v `GLIBCXX_3.4.30' not found (req by libQt6QmlWorkerScript.so.6)
root@rpi4:~# dnf provides */libstdc++.so.6
Updating and loading repositories:
Repositories loaded.
libstdc++-16.2.1-2.fc44.aarch64 : GNU Standard C++ Library
Repo : @System
Matched From :
Filename : /usr/lib64/libstdc++.so.6
libstdc++-16.0.1-0.10.fc44.aarch64 : GNU Standard C++ Library
Repo : fedora
Matched From :
Filename : /usr/lib64/libstdc++.so.6
libstdc++-16.2.1-2.fc44.aarch64 : GNU Standard C++ Library
Repo : updates
Matched From :
Filename : /usr/lib64/libstdc++.so.6
then install the missing package. Repeat for remaining packages on the list.
What you’ll also note is your output above shows /lib64/ whereas my output shows /usr/lib64. The package is installed in my RaspberryPI but not in the location your results shows above.
You didn’t mention what Linux distro you are attempting to run this on. And if it’s Rocky Linux, you didn’t tell us which version - especially since 8, 9 and 10 exists.
My example is from Fedora installed on a Raspberry as you can see by the rpm name. But the dnf command is the same for using under Rocky to find out what package you need to install.
Which allow programs to see, for example the /usr/lib64/libstdc++.so.6 as /lib64/libstdc++.so.6
AFAIK,
el8 has libc up to GLIBC_2.28 and libstdc++ up to GLIBCXX_3.4.25
el9 has libc up to GLIBC_2.35 and libstdc++ up to GLIBCXX_3.4.29
el10 has libc up to GLIBC_2.39 and libstdc++ up to GLIBCXX_3.4.33
The ‘dnf’ requires (indirectly) the libstdc++ and “everybody” requires libc, so some version of them must be installed on every Rocky. Hence it does look like RPi_Imager.AppImage executable is used on Rocky 8, while the executable has been built on platform that has newer library versions.
Unfortunately, AppImages are not 100% universal. They still have a hard requirement on the core glibc version (or higher) of the system they were built on. From your output, it looks like this one needs glibc 2.35 or higher (GLIBC_2.35 appears to be the highest number in the output there).
Rocky 8 (and RHEL 8) has glibc-2.28 , Rocky 9 is glibc-2.34 , and Rocky 10 is glibc-2.39. With these numbers, I think the rpi-imager will only work on Rocky 10 out of the box. Sorry about that :-/ .
The output indicates the oldest missing version is GLIBC_2.29. So I’m guessing this is being run from Rocky 8, or a much older Debian variant of some kind. If you really want this to work, there may be a way to run it under a Rocky10 docker/podman container, but you’d need to run it as root and likely with some host system directories bind-mounted into the container to get the imaging and graphics interface to work correctly.
I’m actually a huge fan of AppImages, but like most software they’re limited by the host system they were compiled/built on: the older the glibc, the more compatible they are likely to be.
Whoops, I was typing at the same time. Good analysis @jlehtone - yeah, the AppImage has a hard requirement on the host system’s libc/libc++ libs. Bummer.
Thx! Yeah, I guess I’ll have to do that, and go through each file.
[quote=“iwalker, post:2, topic:20757”]
The package is installed in my RaspberryPI but not in the location your results shows above.
You didn’t mention what Linux distro you are attempting to run this on. And if it’s Rocky Linux, you didn’t tell us which version - especially since 8, 9 and 10 exists.[/quote]
No, it wasn’t on a Pi - it was to setup a card to be used in a Pi …later.
On Rocky, of course - otherwise I wouldn’t have posted here.
/* I thought adding that green “rocky-linux-8” tag was what we use, to tell what version we’re on. I should’ve put in in the text as well. Sorry. */
Yes, that was sad to see. But, that’s on them (doing an edgy version). I thought the general idea with an AppImage was to escape the “version-djungle”. Ie. a self-contained version.
Well, the card is prep’d now, and I’ll use a usb→serial cable since I couldn’t use their Imager where you can’t set some of credentials. It’ll be fine …hopefully.
If this will be a thing (later). Would it be possible to have a few version (like those 3), like in the extras or plus repos? …since glibc is kindof an important part.
So we’re getting deep into some core Linux/Unix, and the way it works here. Glibc is one of the few pieces of the system that really can’t (easily) be upgraded or substituted. Linux dynamic binaries are generally hard-coded to use the system interpreter, usually /lib64/ld-linux-x86-64.so.2 (named differently for different processor types).
You can’t just throw a newer glibc into /opt/glibc_update/ (or wherever) and use that, at least not without directly modifying the binary files to point to the new location(s). Most Linux distribution versions are built around a single “major” glibc version (2.28, 2.34, etc.) and only update that when crossing major versions. It’s not easily upgradable - literally everything on the system is built around and linked to it, so extreme care needs to be taken when breaking API/ABI changes are made.
It’s rough, but it’s kind of a hard-limit factor when it comes to appimage and other “fat-binary” formats. Even statically linked binaries using glibc have this limitation, iirc.
Unfortunately, AppImage doesn’t use containerization or a chroot strategy (that I know of), and so it’s binaries and libs contained within will always use the system linker /lib64/ld-linux-x86-64.so.2 .
Sorry - I know that’s a mouthful. This is a pretty darn in-the-weeds topic, but kinda foundational to how all this dynamic library/package stuff works in Linux!
Yes, of course. I guess I was thinking if there was a way to add/get a newer versions w/o breaking things, but still be within the RL control. I was prob overthinking it.
I did see a blogpost/guide (»»») now, when searching a little - with one example to put it in an alt path …to use as one-off’s, when needed. I might play around with that later, and if it doesn’t work - I can just remove it. But also, I haven’t need it before and, or used AppImages, so I’ll prob stick to that path.
―
You could try using the RPI Imager that’s available in Flatpak. That will be more self-contained, and more likely to work than the Appimage. Worth a shot.
I see there’s a cli-version inside the AppImage »»». It prob won’t help, but a lot of the err’s were qt6 related. That would’ve been really nice if they could offer like an alt standalone TUI version, say like nmtui-style.
Yeah, I guess I’ll have to do that, and go through each file.
