I distribute binary packages of libgourou in both compiled version (tar.gzip) and AppImage (and maybe .deb in the future). AppImage is a quite old packaging system (2004), not deprecated, but that evolve slowly. It allows to run application without the need to install additional libraries (all is bundled into one binary package). There is not so much tools for building an Appimage and I had to rely mines on a Python bundle not really maintained on Github. Not perfect, but does the job and result worked fine for a while. Unfortunately, starting this summer, there was an issue in running packaged applications. It took me a lot of time to find it, but I finally did it !

First, let's try to run already packaged AppImage

> cd /tmp/libgourou_utils-0.8.7-x86_64.AppImage
> ./acsmdownloader -h
Unable to launch '/tmp/.mount_acsmdoKfAEabacsmdownloader'

If you look in details with strace

> strace ./acsmdownloader -h
execve("/tmp/.mount_acsmdojHgmJpacsmdownloader", ["/tmp/.mount_acsmdojHgmJpacsmdown"..., "-h"],
0x561f614f3790 /* 95 vars */) = -1 ENOENT (No such file or directory)

"ENOENT (No such file or directory)" is confusing and really non obvious to understand, because the file is there and has execution permission ! Most of the time, it means you try to run an application that has been compiled for another architecture (x86 32 bits, arm ...).

This error is raised by a core component of Linux systems : ld-linux-XXX.so. It's used to load ELF file into memory and resolve all dependencies (shared libraries). Useful information can be found with file util

> file /usr/bin/tail
/usr/bin/tail: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=0d3a849e80ee804476c13ed25b3b1ba819847b35, for GNU/Linux 3.2.0, stripped

AppImage is an ELF binary statically linked

> file libgourou_utils-0.8.7-x86_64.AppImage
libgourou_utils-0.8.7-x86_64.AppImage: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked,
BuildID[sha1]=b15b018a4f56042ad61c2b9e0504773f7da1ac38, stripped

It contains compiled binaries and libraries in a squashfs filesystem mounted by libfuse (which is its only dependency). We can access to them with

> ./acsmdownloader --appimage-extract
> cd squashfs-root

> strace ./acsmdownloader
execve("./acsmdownloader", ["./acsmdownloader"], 0x7ffdeb43fa30 /* 49 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory

Our core error, let's look deeper

> file acsmdownloader 
acsmdownloader: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter usr/lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=aaefe8dfc25186c9c3bb2c0e254f8ba09cdd7f7b, not stripped

We can see that the path of ld-linux-x86-64.so.2 is usr/lib64/ld-linux-x86-64.so.2 which is invalid !!!. Ahead "/" is missing (it has been removed by builder Python script). Moreover, since version 13 (or a bit earlier), Debian seems to have moved ld-linuxXXX.so from /lib64 to /usr/lib64 which break compatibility.

My solution is to patch binaries with patchelf in AppImageBuilder.yml, after they are copied into AppDir/usr/bin/

find AppDir/usr/bin/ -maxdepth 1 -type f -executable -exec  patchelf --set-interpreter /usr/lib64/ld-linux-x86-64.so.2 \{\} \;