aarch64 arm64 AppImage available?

[leukimi]

aarch64 arm64 AppImage available?

[UltraBlackLinux]

👍 It seems that quite a few distros have given up on shipping an aarch64 build of linphone, so I'd really welcome it if you built an arm appimage

[julonexus]

Hi
Do the official (=binaries on their repo) Qt 5.15.2 support ARM64 on Linux?
I know that it is not the case for mac

[UltraBlackLinux]

On Arch as well as Fedora there are tons of QT packages in the ARM repos, and they all work fine. I don't see why they wouldn't ship them (and the appimage should ship its own binaries anyway)

[julonexus]

That doesn't answer to my question.
Qt 5.15 is not shipped on ubuntu18/20. We have stopped to build the Qt framework because of maintenance and we are using the package directly from Qt.
So if their package cannot be used on ARM64 (like I said, it's the case on Mac), we will not provide this kind of Appimage on best effort.

[UltraBlackLinux]

That doesn't answer to my question.

well I misunderstood your question then. I wasn't entirely clear to me what you meant. If you look here for example you see that fedora has qt 5.15 in its repos.
As I said though, it should not be up to the distros to ship the QT libraries, and they should instead be bundled into the Appimage. It doesn't really make sense to avoid shipping libraries in Appimages. They are designed to be self-contained application bundles that can run anywhere with absolutely minimal requirements.

I don't even see the big maintenance burden.
ArchlinuxARM for example has a PKGBUILD for their ARM builds here: https://github.com/archlinuxarm/PKGBUILDs/blob/master/extra/qt5-base/PKGBUILD
Fedora builds their ARM version with this spec file: https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qt5-qtbase.spec (on fedora however, qt is split into somewhat many parts, so your best bet are probably the archlinuxarm builds. You might be able to just extract the package into the appimage)
What I'm trying to say is that most of the work has already been done by distros like archlinuxarm, so the only maintenance burden for you would be to maybe change one or two build output directories in the build script to/and then copy them out into the appimage.

[leukimi]

Maybe there is a need to describe how macos launches linux AppImages, if it works. All articles about Mac and Qt talk about compiling Qt on Mac and some offer homebrew ideas. I have no clue about how the newest linphone behaves on macos and where it gets its Qt dependencies from. One developer said that Qt5 does not work on macos. Would that mean that Qt6 will be for macos... not sure.

Mac M1 dual boot running Fedora (39) Asahi Remix has Qt5 and runs AppImages just like a regular Fedora 39 x86_64. That is one distro where aarch64 AppImages are useful. Teams-for-linux has arm64 AppImage that runs on Mac M1 Fedora 39 Asahi Remix. I do not have access to Fedora Asahi Remix on a Mac M1 myself, but others are using it and it works.

OBS build service Fedora aarch64 repositories do not work properly for the time being, so even if RPM builds, the result is stuck in a state where nobody can access a package. Hence, the only option is an aarch64 AppImage or build locally for advanced users who can do that and know how to do it.

I tried as a test to create a AppImage using OpenSUSE OBS Build Service by first creating an aarch64 RPM with openSUSE Leap 15.5 as distro which was then made into an AppImage with linuxdeploy. The AppImage file did not launch the window, but as a first try it shows that it would be possible to pull all dependencies into an aarch64 AppImage.

Linphone version 5.2.1 is difficult to compile for aarch64 due to this error in all aarch64 versions of openSUSE:

cd /home/abuild/rpmbuild/BUILD/linphone-desktop-5.2.1/build/linphone-sdk/external/liboqs/src/kem/kyber && /usr/bin/cc  -I/home/abuild/rpmbuild/BUILD/linphone-desktop-5.2.1/build/linphone-sdk/external/liboqs/include -I/home/abuild/rpmbuild/BUILD/linphone-desktop-5.2.1/linphone-sdk/external/liboqs/src/kem/kyber/pqclean_kyber1024_aarch64 -I/home/abuild/rpmbuild/BUILD/linphone-desktop-5.2.1/linphone-sdk/external/liboqs/src/common/pqclean_shims -O2 -g -DNDEBUG -fPIC -march=armv8.2-a+crypto+sha3 -Wa,--noexecstack -Wstrict-overflow -ggdb3 -fembed-bitcode -o CMakeFiles/kyber_1024_aarch64.dir/pqclean_kyber1024_aarch64/__asm_base_mul.S.o -c /home/abuild/rpmbuild/BUILD/linphone-desktop-5.2.1/linphone-sdk/external/liboqs/src/kem/kyber/pqclean_kyber1024_aarch64/__asm_base_mul.S
gcc: error: unrecognized command-line option '-fembed-bitcode'

Fedora 39 does compile on aarch64 but it is not possible to create AppImage from a Fedora RPM.

I tried to figure out how to make cmake or gcc to ignore unknown options fed to gcc. It seems that this option is related to Mac clang somehow. gcc does not have this option and compilation fails.

OBS Build Service is most probably capable of creating a working aarch64 AppImage with Qt libraries or without them. The trial AppImage I built does not launch since I don't know how the files should be placed. linuxdeployqt complained about missing libopenh264.so.6and would not accept any tweaks to have ldd skip complaining. But linuxdeploy did finish and created an AppImage 240 MB and it seems to pull all dependencies, even all Qt and qml. AppImage does not start yet and I have no clue for the moment where all files should be placed in order to launch the window. But as a start, it looks promising. Hence it should not be difficult to create an aarch64 AppImage.

I used openSUSE OBS Build Service with openSUSE Leap 15.5 as distro with cmake 3.27.7 and gcc 13.2.1 to create the RPM and the AppImage was made with linuxdeploy. It should work with Leap 15.6, Leap 16.0 or Tumbleweed as well in theory.

[julonexus]

Thank you for reporting the liboqs error. I think we can do something about that

[UltraBlackLinux]

Linphone version 5.2.1 is difficult to compile for aarch64 due to this error in all aarch64 versions of openSUSE

Hmm, there is an OpenSUSE build of linphone already available, so I think you might just have a bad build setup. See here: https://pkgs.org/search/?q=linphone

I did also just stumble upon the following, allowing you to seemingly deploy an aarch64 appimage with ease, just pretty much getting the debian (or another distro's - or your own for that matter) package and converting it it haha https://docs.appimage.org/packaging-guide/converting-binary-packages/pkg2appimage.html

[leukimi]

Please test-and-tell-if-it-worked Linphone-Desktop aarch64 AppImage

cd $(xdg-user-dir DOWNLOAD)
outputFile="linphone.AppImage"
arch=aarch64
wget -O "$outputFile" "https://download.opensuse.org/repositories/home:/kimi:/linphone-desktop/AppImage/linphone-desktop-latest-${arch}.AppImage"
chmod +x "$outputFile"
./"$outputFile" -V

AppImage is portable, which means it could be run on equipment which does not allow a guest user to install any packages.

Updating the AppImage is done with appimageupdatetool which also can be compiled as a distribution package:

appimageupdatetool $(xdg-user-dir DOWNLOAD)/"linphone.AppImage"

An upgrade will look like this:

# appimageupdatetool $(xdg-user-dir DOWNLOAD)/"linphone.AppImage"

Checking for updates...
zsync2: Using CA bundle found on system: /etc/ssl/ca-bundle.pem
... done!
Starting update...
Updating from generic server via ZSync
zsync2: Using CA bundle found on system
zsync2: Target file: linphone.AppImage
zsync2: Reading seed file: linphone.AppImage
79.46% done (112.81 of 141.97 MiB)...
zsync2: Usable data from seed files: 97.463270%
zsync2: Renaming temp file
zsync2: Fetching remaining blocks
97.46% done (138.37 of 141.97 MiB)...
zsync2: Downloading from https://opensuse.org/AppImage/linphone-desktop.AppImage
zsync2: optimized ranges, old requests count 43, new requests count 9
99.60% done (141.41 of 141.97 MiB)...
zsync2: Verifying downloaded file
100.00% done (141.97 of 141.97 MiB)...
zsync2: checksum matches OK
zsync2: used 145096704 local, fetched 4573272
100.00% done (141.97 of 141.97 MiB)...
Update successful. New file created: linphone-desktop.AppImage

which then pulls just the difference and not the whole file if not needed. This is maybe one of the advantages with using OBS Build Service AppImage creation. For curiosity I tried to update the Linphone AppImage downloaded from the Linphone web link:

# appimageupdatetool Linphone-5.2.1.AppImage

Checking for updates...
Could not find update information in the AppImage. Please contact the author of the AppImage and ask them to embed update information.
Update check failed, exiting!

For reference x86_64 AppImage

cd $(xdg-user-dir DOWNLOAD)
outputFile="linphone.AppImage"
arch=x86_64
wget -O "$outputFile" "https://download.opensuse.org/repositories/home:/kimi:/linphone-desktop/AppImage/linphone-desktop-latest-${arch}.AppImage"
chmod +x "$outputFile"
./"$outputFile" -V

---

Run x86-64 AppImages on aarch86

I stumbled across this topic which may benefit somebody:

Run x86-64 AppImages on aarch86/arm64 via box64 emulator

box64

---

Discussion

I suspect that Debian might be the best tool for creating AppImages overall (I may be wrong). My suspicion is that Debian creates smaller AppImages than openSUSE Leap does.

I couldn't get my head around an error Qt_5.15.12_PRIVATE_API that would halt AppImage creation. I suspect that a distribution that has exactly Qt 5.15.12 (LTS-version of Qt) would be needed. Maybe it would work with a later Qt 5.15.x. openSUSE Leap 15.6 (not yet released) has that Qt version. Since the latest is openSUSE Leap 15.5, there are no tools to do the AppImage. That means there is first a need to develop the AppImage tools that are needed by compiling packages with those tools. Most of the process is undocumented so it means a lot of trial-and-error to figure out how it maybe is supposed to work. It is quite experimental. Most of the times openSUSE Leap 15.4/15.5/15.6 can be used for AppImage creation.

First I made a simple leafpad AppImage with openSUSE Leap 15.4 just to test the tools. leafpad appears in some tutorials as a small gtk example app. The target was to see if aarch64 AppImage could be created with the tools only used for x86_64.

Then I AppImaged a small Qt app (MediaElch).

Then I saw that linuxdeploy made an earlier version of Zoom AppImage via github. So github can also produce AppImages. I wondered if the most recent version of Zoom could be AppImaged. Zoom installs in /opt/zoom directory and most of it's libraries are in the same directory as the executable, except for one cef library, which of course cannot be found at launch time. Setting the LD_LIBRARY_PATH to the missing library before linuxdeploy made it work.

The learnings from Zoom AppImage creation were then transferred to attempting the same on Linphone x86_64. The AppImage that @julonexus makes look very different and I am not sure where all the files should be placed inside the AppImage. If the linuxdeploy yaml recipe could be transferred to OBS Build Service somehow, maybe the resulting files would be smaller.

I attempted to dump the installed files in /opt/linphone directly into an AppImage. Added a launcher to /usr/bin/linphone-launcher that adds a relative LD_LIBRARY_PATH to /opt/linphone/lib64 and a relative path to /opt/linphone/bin/linphone. Using absolute paths will search outside the AppImage on the system. So in order for an AppImage from RPM to work, a bash script has to figure out where the launcher is and then calculate the relative path to the executable inside the AppImage with a correctly calculated LD_LIBRARY_PATH which is also relative to the launch script.

The alternative would either compile linphone to /usr straight away, or maybe to move each file to the correct location in /usr and hope that all libraries are found where the executable is looking for them. RPATH and all that. Since many third party apps install to /opt/, I thought it would be interesting to try to AppImage such an app.

Finally I checked the latest commits to linphone-desktop here on github. 5.3.0-alpha.36 in main branch has the same gcc: error: unrecognized command-line option '-fembed-bitcode'. However, tag 5.2.2 does compile on aarch64. I tried to aarch64-compile versions 5.0.18, 5.1.0, 5.1.1 (almost compiled on one attempt on one machine, but mostly stalled on 60% without a reason given in log), 5.1.2, 5.2.0, 5.2.1. So v5.2.2. is probably the first aarch64 release that compiled on aarch64.

Thank you @julonexus for fixing the compilation.

[julonexus]

Hi,
The master branch of linphone Desktop doesn't follow exactly the SDK's version. But the fix is into the master of SDK. It can be used.

We build the Appimage from this script : https://gitlab.linphone.org/BC/public/linphone-desktop/-/blob/master/linphone-app/tools/create_appimage.sh

The main limitation of building an Appimage is the glibc version of the system.
For example, we choose to build on Ubuntu20 : the glibc is 2.31. Then all systems under this version cannot run the Appimage (like Debian10/Rocky8,Ubuntu18... from https://ftp.gnu.org/gnu/glibc/ : all systems before 2020-02-01).

But in all case, we won't change the build system before the LTS of Ubuntu20 (around 04/2025)... if we are still on a 5.x ;).

[leukimi]

Thank you!

I may be able to port the script to OBS Build Service and use AppImages. My issue is with selecting openSUSE Leap 15.x low-enough-glibc with high-enough-Qt-cmake-gcc and make it all work. I try to explain in detail below.

---

To my understanding, there is very little knowledge about the inner workings of a Qt-app in AppImage format. Many assume it is 100% portable, not knowing about the glibc limitation. It is not obvious one has to use an old distro for the AppImage process.

Which distro is best for AppImage creation is in itself a topic. Most tools are developed for Ubuntu (maybe for Debian). That puts openSUSE Leap at an disadvantage of being "too new" sometimes.

Qt backward compatibility is also a topic. If exactly Qt 5.15.12 is needed and it cannot be newer, that also affects the process. Changing opensource decisions may also impact development decisions (which versions one can use long term) and adaptations of the code. Qt6 is maybe one such aspect forcing adaptation.

If I understand the task correctly, there is a need to find an old openSUSE Leap with glibc 2.31 or lower.

openSUSE Leap 15.6 which has the high enough Qt version has glibc 2.34. Either I get the Qt-version right and miss on glibc version, or I get the glibc version right, but not the Qt-version, and maybe it does not even compile on an old distro unless I update specific packages like cmake and gcc.

1. openSUSE OBS Build Service would probably need to use a really old distro (Debian or Ubuntu) with an old glibc for AppImage creation.
2. Add a newer stand-alone Qt 5.15.12 LTS-version of choice in a separate stand-alone directory which does not mess with the system's Qt-version. I read somewhere that the Qt 5.15.2 version is opensourced. Not sure if Qt 5.15.12 is opensourced. This further complicates the task for an OBS Build Service approach.
3. I think the conclusion is that AppImages would have to be made on a standalone system dedicated just for AppImage creation. I assume that a GTK-based app (like leafpad) is easier to AppImage in an old system than a Qt-application.
4. Then port all the code needed both for compilation and AppImage creation to the old distro, or use AppImages like your script does.
5. The old distro would probably need to add a newer cmake and a decent gcc and it should build. openSUSE Leap 15.5 and 15.6 both have older versions of cmake.
6. Mixing old system with low glibc with new software is often not super easy, so I kind of understand that properly made aarch64 AppImages will take time to develop. For now, I think the best is to just make everything compile on aarch64 and be installable. Aarch64 may attract more users sooner or later and then it will maybe be a normal thing. Chances are that arm based mobile devices using Ubuntu Touch or similar will play a role in how many shift to arm systems.

I wonder if an aarch64 build system inside a KVM/QEMU virtual machine running aarch64 could do the same build as you do today on Ubuntu 20.04 LTS x86_64. I think I see your point earlier that although it is doable, it may not be trivial unless there is a specific arm64 hardware for it (like a newer Raspberry).

Although I suspect that the aarch64 AppImage that was built with OBS Build Service is functional, the glibc version is simply too high to allow for proper portability to older distros.

What maybe could be of use is the zsynch2 update capability if you wish to add it to your own AppImages, reducing the load on your servers when users update. Such an AppImage update could also be scheduled with cron/anacron so that AppImages update themselves, which is kind of what would be interesting to mimic the Android experience, where apps upgrade in the background without user intervention.

At least we know OBS Build Service and probably also Github can create aarch64/arm64 AppImages, even though it's not perfect and has a too high glibc.

[leukimi]

glibc 2.29 Qt5.15.12 AppImage aarch64 with OBS Build Service openSUSE Leap 15.5

I was able to get a prototype AppImage aarch64 with glibc 2.29 with openSUSE Leap 15.5 on OBS Build Service. Compiled Qt5.15.12 and cmake 3.27 separately. The Qt-libraries are large for some reason (I might have added too many devel packages to Qt compilation) which makes the AppImage roughly 450 MB in size.

linuxdeploy seems to pull the entire separately compiled Qt5.15.12 into the AppImage and making it 1.5GB in size.

The workaround is to lift in specific needed Qt-libraries and its dependencies and make sure that the RPM being transformed does not contain any libQt* requirements. Some needed libraries are not pulled in automatically and have to be added manually.

Compiling linphone-desktop into prefix /usr causes conflicts at AppImage generation on OBS Build Service. Compiling with prefix /opt/linphone resolves that issue.

It is definitely doable to create an aarch64 AppImage with glibc 2.29 and Qt5.15.12 with the help of OBS Build Service, although it may require some manual adjustments to the process to get the file size down to 100-130 MB in size.