I’ve read through the AppImage docs for the most part and haven’t really been able to find anything on this, but is there any standard way to specify the minimum Glibc to run the AppImage? This would be useful so a custom AppRun could automatically check if an AppImage is compatible with your system on launch, then return a user-friendly error message instead of simply crashing with no graphical feedback
2 Likes
Ideally the AppImages would be able to run with the lowest possible version of Glibc to ensure maximum compatibility. Perhaps 2.23? (Ubuntu 16.04)
If there are big changes in features that mandate a minimum version, that would be important to be aware of.
1 Like
This is really really bad answer.
For example i use “renameat2” system call and that was added 2.28 so what will happen?
Either you have a script that checks the dependencies function by function and selects the correct glibc (would of course never work as you can’t check passed constants) or you let the developer specify it.
There are two purposes for AppImage, running on old system and running on different distributions. I don’t want to restrict my application with the first one. We had this discussion already, please reconsider your practice here. That you suggest restricting ourself to a 11 year old release of glibc is leaving me speechless.
1 Like
While that would be ideal for compatibility reasons, like Illothar said, it’s not possible for every application. Even if it were, sometimes it can be incredibly hard to find any relatively modern version of a library compiled for such an old version of Glibc. Also adding, since static compiling seems to be very discouraged in the Linux community, it’s almost guaranteed that at least one necessary library in a large program doesn’t support static linking at all and probably won’t even compile, making that a non-option for many cases as well.
Imo the closest compromise would be to have another optional flag in the desktop file, such as “X-AppImage-GCC”, so that the AppImages which can’t exist on GCC 2.23 at least have a standard way of communicating their compatibility instead of either crashing or having to implement their own warnings, which ultimately just puts unnecessary work on the developer
We currently have no way to specify the minimal glibc version needed.
But we recommend to build AppImages on no newer distribution than the oldest still-supported LTS release of Ubuntu. This is also the requirement to be listed on AppImageHub.
Tools like go-appimage and GitHub - AppImageCrafters/appimage-builder: GNU/Linux packaging solution using the AppImage format can bundle everything in the AppImage, including glibc, and hence can produce AppImages that can run even on older systems than the one used for compiling.
Honestly I wasn’t even aware that packaging Glibc was possible, this looks like an amazing tool for max compatibility in exchange for a larger file size. Out of curiosity though, is adding something like this a feature you’d be interested in? I’d be happy to whip up an alternative AppRun that looks for a dialog implementation (zenity, kdialog, etc) on the host system in case an error occurs
appimage-builder and the appimagetool in go-appimage can bundle glibc.
But it comes with downsides as well (the moderate sub-10 MB size increase not being the only one).
We do not want AppImages to show additional dialogs (been there, done that more than once.)