[Nemo-010]

Greetings from Port Edwards. Updates quick-sharun to sharun 3.7.1 and turns on the emulated arches for four demos. Rebased on current main, so it now includes the APPIMAGE_ARCH override and the performance work from #965–#968.

sharun 3.7.1

3.7.0 reverted the embedded shell of 3.6.0 and ships the same patched dash as a dash file inside sharun+helper-libs-<arch>.tar. sharun runs AppRun.sh with <sharun dir>/dash when it is executable, and falls back to the host shells otherwise. 3.7.1 adds the BSD-3-Clause notice for it as dash-COPYING. All six checksums are updated and each was checked against the release's own .sha256 files.

That matters for the second half: the embedded dash of 3.6.0 was a foreign-arch ELF in a memfd, so under qemu user emulation binfmt_misc had to run it, and the kernel refuses to hand a close-on-exec fd to an interpreter. Every emulated AppImage died in AppRun.sh before the app started.

quick-sharun now deploys dash. It only extracted sharun, so without this the dash never reached the AppDir and the shell was silently looked up on the host again, which is the /bin/sh dependency the dash exists to remove:

• _get_sharun extracts dash into the AppDir root next to sharun and chmods both.
• dash is extracted separately from sharun. It is not in tarballs older than 3.7.0, and asking tar for a member that is not there fails the whole extraction. If it is missing the build warns and continues.
• The early return checks dash too, so an AppDir that already has sharun does not skip the download and end up without a shell.
• dash-COPYING goes to APPDIR/share/licenses, and only when the tarball has it, so 3.7.0 and older do not leave an empty directory behind.
• _add_helper_libs deletes dash and the notice from the preload dir, since they belong next to sharun.

Checked against three real tarballs: 3.7.1 gives sharun, dash and share/licenses/dash-COPYING; 3.7.0 gives sharun and dash with no empty share/licenses; 3.5.1 warns and keeps a working sharun. In all three lib/sharun-preload ends up with only the helper libs.

Emulated arches

A build-additional-cpu-arches matrix builds the gtk3, gtk4, sdl and vkcube+glxgears demos for riscv64, loongarch64, ppc64le and ppc64 through qemu user emulation, and runs them. The binfmt handlers are registered before the container starts, with the script of anylinux-setup-action, because docker/setup-qemu-action ships no ppc64 (BE) handler. The release job waits for that matrix with the same !cancelled() guard as the template.

ppc64le, loongarch64 and riscv64 do have vulkan drivers in their repos, we just do not bundle them, so vkcube works there; only BE ppc64 predates vulkan and makes glxgears its main binary. vulkan-swrast is installed for the test on every arch — it is packaged for powerpc64 too.

The sdl demo keeps plain sdl2, which sdl2-compat provides on riscv64 and loongarch64.

Tested

Full matrix run on my fork against this exact tree: 15 of 16 emulated jobs green, including every vkcube job with a plain pacman -S vulkan-swrast. The one failure is gtk3-demo-appimage (ppc64le), where the AppImage builds and starts, then exits with code 0 inside the 12s test window — the demo app quitting early, which it also did before this change.

Worth noting for review: an earlier revision of this PR needed --overwrite when installing vulkan-swrast on the four emulated arches, because the debloated mesa shipped mesa's layer files that upstream puts in vulkan-mesa-implicit-layers. That was a packaging bug and is fixed upstream in pkgforge-dev/archlinux-pkgs-debloated#95; the rebuilt packages no longer carry those files, so this PR installs vulkan-swrast normally and the workaround is gone.

---

We aim to provide the software that shapes the world of tomorrow.

---

Requested by Samueru via errand.
Conversation: https://discord.com/channels/1313385177703256064/1561764843965649021

[Nemo-010]

Updated to cross-libc-dlopen v0.2.8 (4a04ab1), which carries the ppc64le resolver fix from pkgforge-dev/cross-libc-dlopen#60.

The bug was glfwd_resolve_asm saving the argument registers inside the ABI's own frame header, so glfwd_resolve_one overwrote the saved r5 and r6 on the first call through every slot — any GL entry point taking a third or fourth integer argument got garbage. That is what was segfaulting gtk3-demo on ppc64le, and it is why only that one job in this matrix was failing.

Checked in the released binary rather than assuming from the version number: the ppc64le gl-fwd.so in v0.2.8 starts with stdu 1,-288(1) where v0.2.7 had the buggy -192. All five tarball checksums are updated and each was verified against the release's own .sha256 files.

Full matrix run against this tree: 41 jobs, 40 success, 0 failures (the 41st is the release job, skipped on a non-main ref). gtk3-demo-appimage (ppc64le) now passes, along with all 16 emulated jobs.

One gtk4-demo (x86_64) failure in that run was a transient GitHub API rate limit while downloading debloated packages (ERROR 403: rate limit exceeded); it passed on re-run and is unrelated to this change.

[Samueru-sama]

@Nemo-010 rebase

[Nemo-010]

Rebased onto cc74623 (#970). Head is now e4117323.

#970 rewrote _lib4bin_deploy_shared_libs and _lib4bin_deploy_binaries; my change touches _get_sharun, _add_helper_libs and the download/checksum block, so there was no overlap and the rebase applied without conflicts. I checked both sides survived rather than assuming: the _cache_src/bin_basename rework from #970 is intact, and so are the sharun 3.7.1 dash deployment, the dash-COPYING handling and the v0.2.8 checksums.

Re-verified the whole matrix on the rebased tree, since #970 changed the library deployment path that every demo goes through: 41 jobs, 40 success, 0 failures, with gtk3-demo-appimage (ppc64le) still passing.

One gtk4-demo-host-drivers (x86_64) failure in that run was a pacman mirror timeout (Operation too slow. Less than 1 bytes/sec), not a code fault; it passed on re-run.

[Nemo-010]

Split done. The dependency bumps are now their own PR: #973, one file, useful-tools/quick-sharun.sh, sharun 3.5.1 -> 3.7.1 and cross-libc-dlopen v0.2.7 -> v0.2.8.

This PR now carries only the demo matrix: .github/workflows/build-demos.yml and useful-tools/demo/vkcube-glxgears-appimage.sh, one commit, +55/-2.

It is stacked on the deps commit rather than branched from main, and that is deliberate rather than leftover: the ppc64le gtk3 job here needs cross-libc-dlopen v0.2.8 to pass. Against upstream main alone that job fails, because v0.2.7 carries the resolver bug that segfaulted GTK3 on ppc64le (pkgforge-dev/cross-libc-dlopen#59). So once #973 merges this becomes a one-commit diff on its own; until then it shows both.

I did not re-run CI after the split: the tree at f255d5d is byte-identical to e411732, which I already verified green at 41 jobs / 40 success / 0 failures with gtk3-demo-appimage (ppc64le) passing. Same tree, so the result carries over rather than needing a fresh run.

[Nemo-010]

Superseded by #974, which carries the same commit from its own branch so the fork's main can go back to matching upstream. #973 merged in the meantime, so #974 is a single clean commit on current main. Closing this one rather than leaving two identical PRs open.