Provide aarch64 AppImage

[Samueru-sama]

Suggestion

Please consider providing aarch64 builds for the AppImage.

[abcfy2]

We use linuxdeployqt to prepare and build AppImage. But currently it only provide amd64 arch. So after we can find an alternative to linuxdeployqt and support aarch64, we can provide the aarch64 AppImage soon.

[Samueru-sama]

We use linuxdeployqt to prepare and build AppImage. But currently it only provide amd64 arch. So after we can find an alternative to linuxdeployqt and support aarch64, we can provide the aarch64 AppImage soon.

I think it is time to move away from linuxdeploy-qt

Recently I've been making appimages that deploy all the dependencies (that is they work on any linux system including musl distros).

see 1 2 3

This also makes it easier for me to add theme support like I did here.

So this week I should have time to experiment, in theory all that needs to be done is build on a alpine container (since the produced binaries are smaller here) and manually deploy all the libs and the needed qt plugins, which deploying the qt plugins is just copying the directories and changing their rpath with patchelf.

[abcfy2]

Yeah. You're right. I have considered replacing linuxdeployqt before, because linuxdeployqt is currently lacking maintenance, and the author's focus has shifted to go-appimage.

I have also reviewed go-appimage before. It's amazing and support so many Linux targets.

But it does not fully implement the functionality of linuxdeployqt yet. Mainly -extra-plugins and -exclude-libs in linuxdeployqt (That's why our AppImage is only 25MB, but official qbittorrent AppImage is ~98MB). see: probonopd/go-appimage#291

Lack of documentation is another aspect. I could hardly find a complete description of the CLI parameters for go-appimage.

Once go-appimage achieves the same functionality as linuxdeployqt, or other alternatives have such functionality, I will replace it without hesitation and support aarch64 AppImage as soon as possible.

Thanks @Samueru-sama

[Samueru-sama]

Note that -exclude-libs is not really possible if all libs are going to be deployed, which is needed for the appimage to work on any linux system.

-extra-plugis As far as I know go-appimage deploys more Qt plugins by default than linuxdeploy-qt, but extra plugins can still be added manually, all that would need to be done is copy the plugins/plugin_name dir in the plugins dir of the appimage and use patchelf to change the rpath of the libs to be the same as the one of the other plugins.

Lack of documentation is another aspect. I could hardly find a complete description of the CLI parameters for go-appimage.

There is only two modes.

• go-appimagetool deploy ./AppDir/usr/share/applciations/*desktop which will make a regular appimage that still depends on the host libs, aka similar to the current appimage.

• go-appimagetool -s deploy ./AppDir/usr/share/applciations/*desktop which will bundle all libs including the ld-*so which makes it work on any linux system, be it 10 years old or musl.

For the appimage to still be small building should be shifted to a alpine container instead and deploy everything to still make it work on glibc systems, this makes it very reliable as well since it doesn't depend on host libs, but it is likely that it will still be +50 MiB, I would need to test, my puddletag appiamge is a whole python env with pyqt5 and graphic libraries included and ended up being 50 MiB and the Mpv appimage is 25 MiB because it has a statically linked ffmpeg instead of just copying all the ffmpeg libs lol.

[abcfy2]

-extra-plugis is used to exclude the libs that the UI component libraries directly or transitive depends on (like libX11, gtk, wayland and so on). To minimize dependencies, I used readelf -d to check all *.so files packaged into AppImage to ensure that no other transitive dependencies were included (not using ldd because ldd does not distinguish directly and transitive dependencies).

Why I exclude all the UI component libraries (libx11, gtk, wayland and so on) ? I think we only run this AppImage in a deskop environment, so that libraries should be provided by the desktop environment. In this way, we can not only minimize the package size, but also effectively use the current desktop environment theme.

I have tried many AppImage packaging tools before (like linuxdeploy, linuxdeployqt, and so on). Using the default dependency packaging parameters will bundle so many direct or transitive dependencies of X11, this will cause so many issues, like:

• Strange style, inconsistent with the current desktop environment theme experience
• Segmantfault crash
• Poor compatibility, it can run on some distributions but not on others

So I decided to minimize dependencies and not bundle any libraries that the target system should provide, especially UI libraries.

So far working very well.

Thanks.

[abcfy2]

For the appimage to still be small building should be shifted to a alpine container instead and deploy everything to still make it work on glibc systems

Yeah. I've thought about this before. In fact, our -nox cross compile does this: https://github.com/c0re100/qBittorrent-Enhanced-Edition/blob/v5_0_x/.github/workflows/cross_build.sh

I even considered building it all statically with musl-lib. But finally I gave up, —— it was too heavy, I needed to build almost the entire UI component libraries from scratch (but nox only needs qt, zlib, openssl, libtorrent)

In addition, building the UI libraries may also cause compatibility issues between different distributions and different desktop environments, so I finally took the oldest available Ubuntu LTS (currently it's ubuntu 20.04 but requried at least 22.04 to run this build) based on glibc and excluded the UI component dependency.