[gianlucarenzi]

This adds three architectures to appimagetool: riscv64, ppc64le and big endian ppc64. It needs the runtimes for them, proposed in AppImage/type2-runtime#156: until that is merged, the CI jobs of the new architectures here cannot download runtime-<arch> from the continuous release.

Recognizing the architectures

• riscv64: ELF e_machine 243, or ARCH=riscv64;
• ppc64le: e_machine 21 with ELFDATA2LSB, or ARCH=ppc64le, ppc64el (Debian) or powerpc64le (Rust, LLVM);
• ppc64 (big endian): e_machine 21 with ELFDATA2MSB, or ARCH=ppc64, ppc64be, powerpc64 or powerpc64be.

The names in the files are those of uname -m. To tell the two PowerPC apart, read_elf_e_machine_field() now reads the byte order; before, it read e_machine always as little endian, so a big endian AppDir was never recognized (EM_PPC64 came out as 0x1500): that is a separate commit. The number of architectures is no longer hardcoded (fARCH_COUNT).

It needs #133 (section headers in the byte order of the file), without which packing a big endian runtime on a little endian machine crashes. #133 is merged now and the branch is rebased on main, so its commit is no longer part of this PR.

#148 (only use ELF files for determining the architecture) changes read_elf_e_machine_field() too: whichever is merged second needs a small rebase.

Building appimagetool for them

• riscv64 and ppc64le: Alpine containers emulated by QEMU (setup-qemu-action), as there are no GitHub runners for them; riscv64 needs alpine:3.20 (3.19 has no riscv64 images).
• ppc64: Alpine has no big endian ppc64, and Debian has no static builds of all the dependencies, so ci/build-in-debian.sh builds it in Debian ports (sid), linked dynamically against the glib, gpgme, libgcrypt and libcurl of Debian, and puts the libraries it needs but glibc into the AppImage (usr/lib, found through LD_LIBRARY_PATH set by AppRun), with mksquashfs, zsyncmake and desktop-file-validate from Debian. The build checks that nothing but glibc is left outside. The CI job makes the system with debootstrap and runs it with the qemu-user-static of Ubuntu.

Tested

• The CI of this branch (in a fork, with the runtimes of the type2-runtime PR) builds appimagetool for all the architectures, the new ones included.
• The CI here, after the rebase, builds appimagetool for riscv64, ppc64le and ppc64 too (7 to 11 minutes under QEMU); those three jobs fail only afterwards, when they download runtime-<arch>, which the type2-runtime continuous release does not have yet.
• appimagetool for x86_64 packs AppDirs of riscv64, ppc64le and ppc64 (detected from the ELF files or given with ARCH, all the names above), with update information and .zsync.
• RITMO, a Qt 6 application, packed this way on riscv64, ppc64le and ppc64, starts and runs emulated by QEMU (https://github.com/gianlucarenzi/RITMO-Music-Tracker).
• Not tried on real riscv64 or POWER hardware yet.

Built AppImages of appimagetool: https://github.com/gianlucarenzi/appimagetool/releases/tag/ports-2.

[probonopd]

I read the five commits (the first is #133) and the build scripts. The source changes are correct; the CI part has dependencies and the same open points as type2-runtime#156.

Source (commits 2 and 3): correct. read_elf_e_machine_field() now reads EI_DATA and converts e_machine with GINT16_FROM_BE for big-endian files, which fixes the 0x1500-for-0x0015 misread. EM_RISCV is 243 and EM_PPC64 is 21 for both byte orders, so splitting ppc64 and ppc64le on EI_DATA is the right way. fARCH_COUNT replaces the hardcoded 4 in count_archs() and in main()'s archs[], which was easy to miss when adding entries. One fragile spot, not wrong: the ARCH text matching relies on the n of g_ascii_strncasecmp() including the terminating nul ("ppc64" with n=6) so that ppc64 does not also match ppc64le. It works, but an exact g_ascii_strcasecmp() would say what is meant and not break when someone adjusts a length.

Dependencies, before this can be green:

1. fetch_runtime() downloads runtime-<arch> from type2-runtime's continuous release, and ci/build-in-debian.sh does the same with wget. That release has only aarch64, armhf, i686 and x86_64 today, so the riscv64, ppc64le and ppc64 jobs cannot finish until type2-runtime#156 is merged and has published its runtimes; users of the new architectures need --runtime-file until then. Merge order is #133, then type2-runtime#156, then this.
2. The ppc64 appimagetool is built on Debian sid and linked dynamically against sid's glibc, with the other libraries bundled. It will therefore only run on ppc64 systems with a glibc at least as new as sid's at build time, unlike the other architectures, whose static musl builds run anywhere. Since ppc64 exists only in Debian ports, that is inherent to the approach; it should be documented on the release page so users know.

CI, same points as on type2-runtime#156: the upload job now needs: build-debian-ports, so a failure of the emulated four-hour Debian job blocks the release for every architecture; the keyring is pinned to debian-ports-archive-keyring_2026.02.04_all.deb in the Debian pool, which keeps only the current version, so that URL breaks on the next keyring upload. At the time of writing, the aarch64 and armhf builds of this PR have passed and the others are still running.

---

Generated by Claude Code

[gianlucarenzi]

Thanks, @probonopd. c96d17a: the new ARCH names are compared exactly with g_ascii_strcasecmp(); the Debian ports keyring is resolved from the package index; the upload job no longer depends on the ppc64 job; and the README now documents the riscv64/ppc64le/ppc64 builds, the glibc requirement of the ppc64 build, and --runtime-file until type2-runtime publishes the new runtimes. Merge order as you suggested: #133, type2-runtime#156, then this one.