c0re100 / qBittorrent-Enhanced-Edition

[Unofficial] qBittorrent Enhanced, based on qBittorrent
https://github.com/c0re100/qBittorrent-Enhanced-Edition
Other
19.74k stars 1.26k forks source link

Provide aarch64 AppImage #598

Open Samueru-sama opened 1 month ago

Samueru-sama commented 1 month ago

Suggestion

Please consider providing aarch64 builds for the AppImage.

abcfy2 commented 1 month ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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: https://github.com/probonopd/go-appimage/issues/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 commented 3 weeks ago

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.

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 commented 3 weeks ago

-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:

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 commented 3 weeks ago

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.