Ok, I have done some digging on the origin of the restriction. Basically the answer is that it’s the arbitrary choice of one dev.
The AppImage documentation recommends building the binary on as old a Linux distribution as possible in order to have compatibility with as wide a range of distros as possible. However, this is not mandated by the spec and an AppImage can be prepared using any binary and any set of libraries on any distro; indeed, it’s sometimes recommended to prepare AppImages for multiple target distributions.
linuxdeployqt
is what is being extremely opinionated here, and seeks to enforce the above recommendation by raising errors and refusing to run if “recent” distributions are used. “Recent” is currently defined by the developer as either the oldest still-supported LTS release of Ubuntu, or more specifically as a distro using a glibc
no newer than 2.31.
We wouldn’t be the only people to complain about how limiting linuxdeployqt
is. It has been pointed out that 20.04 isn’t even supported by Qt for Qt6 development.
Importantly, I’ve found there are ways round this.
As one possibility, we can run linuxdeployqt
with the flags -unsupported-bundle-everything -unsupported-allow-new-glibc
. This is explicitly unsupported, so the dev doesn’t want to hear from any issues while using it, but it apparently works just fine.
But the other thing is that we aren’t obliged to use linuxdeployqt
, as it’s not even the only tool that can bundle Qt for an AppImage. There’d be other reasons to think abotut moving away too; the dev says he’s no longer working on the codebase. He focusses on go-appimage
instead, which is also what he recommends if you need to use newer Ubuntu releases. The tool also explicitly doesn’t support Wayland (the dev says he has no desire to do anything towards this, even in 2023).
go-appimage
is one option, but honestly doesn’t seem super established. There are two better options:
-
appimage-builder
, which takes a different approach; it bundles much more stuff with the AppImage by default, including glibc
and SSL libraries, plays better with environment variables, etc. This would solve the SSL issue, and would allow building the Qt6 AppImage on 22.04. It has examples for Qt builds. But it would make the AppImage 30Mb larger (though I really don’t see Avogadro’s size as a problem, and people who do care are unlikely to use the AppImage anyway because it bundles Qt).
-
linuxdeploy
, which was actually envisaged as the successor to linuxdeployqt
and seems to be the most established solution. The official AppImage documentation uses it in its packaging guide. It’s used by AppImageLauncher and appimaged.
linuxdeploy
can work with an existing binary (i.e. as a drop-in replacement for linuxdeployqt
) but it can also build from source in conjunction with cmake.
It has a plugin system, and there’s a list of plugins over at awesome-linuxdeploy. The Qt plugin explicitly supports Qt5 and Qt6! There’s even a plugin that bundles and sets up miniconda…
Of course, the last option is to just assemble the AppImage manually, though this seems tedious.
One last thing – there’s also a project for AppImages with bundled Python.