Message 'ELF file ABI version invalid'

[Ricky-Tigg]

General information

$ cat /etc/redhat-release
Fedora release 36 (Thirty Six)
$ uname -ro
5.18.9-200.fc36.x86_64 GNU/Linux
$ phoronix-test-suite system-info | grep 'Display Server'
    Display Server:       X Server 1.20.14 + Wayland

AppImage file properties

$ file -bk LO.AppImage
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6092ddf6a719ff37b93e84522102c50b097b86ad, stripped\012- data

Hello. The application would run as intended without requesting explicitly the interpreter, be it outside or inside a sandbox program – firejail for instance, e.g. via firejail --appimage --private --noprofile ./<AppImage>, assuming the support of AppImage is enabled, which can be checked against firejail --version.

• Here is the illustration of the message present while requesting above reported program interpreter and whatever the type 2 of AppImage-format file that have been involved in my tests, which might be an indication of an issue.

$ /lib64/ld-linux-x86-64.so.2 ./LO.AppImage
./LO.AppImage: error while loading shared libraries: ./LO.AppImage: ELF file ABI version invalid

$ ldd /lib64/ld-linux-x86-64.so.2 ./LO.AppImage
/lib64/ld-linux-x86-64.so.2:
	statically linked
./LO.AppImage:
	not a dynamic executable
$ readelf -n ./LO.AppImage | grep 'ABI:'
    OS: Linux, ABI: 2.6.32

Note: the conversion into AppImage-format file was achieved against an existing binary package in .deb format, for instance from LibreOffice, by observing the methodology on that same platform present within the antoniofaccioli repository, which is viable, instead of the one promoted by this very repository (pkg2appimage), which obviously lacks a concrete example for this purpose.

• Commands executed for operating the conversion.

$ wget https://raw.githubusercontent.com/antoniofaccioli/libreoffice-appimage/master/make_libreoffice_appimage -O LO.sh
$ chmod +x LO.sh
$ ./LO.sh daily x86-64 N N N N Y

[probonopd]

This is probably an unintended side effect of adding the AppImage magic bytes (0x4149nn at offset 8).

For a future version of the AppImage spec, we are considering to put the AppImage magic bytes at another offfset.

[Ricky-Tigg]

Seems a duplicate of AppImage/AppImageSpec | #15.

[Ricky-Tigg]

Planning to close reports of mine on this platform that remain open indefinitely in undone/unfixed states soon, rather than continuing to keep them in such states, which would not be healthy for the project owner.

[probonopd]

My philosophy on this is that issue tickets should be closed only once the issue is fixed. Nobody doing anything never is a reason to close anything imho.

So, the current hypothesis is that this issue is caused by the magic bytes in type-2 AppImages, so most likely this issue will go away once there is a newer version of the AppImage format with the magic bytes at another location. At that point in time, this issue should be retested and if it is no longer an issue, it should be closed.

Thanks for your patience @Ricky-Tigg.

[probonopd]

Well, this is obviously a bug that needs to be fixed in a future version of the AppImageSpec.

• Where to embed AppImage magic bytes in the future? AppImageSpec#26