Run Spelunky and other Android Game Maker games on Pi5 / arm64

Lolonois

With the advent of the Pi5 and the increased popularity of arm64 bit the droidports (Game Maker Loader) did no longer compile and run.

I provided a solution for the gmloader.sh scriptmodule which crosscompiles on the Pi5/arm64 a 32bit binary of gmloader.

In case you missed Spelunky: https://www.polygon.com/2019/11/8/20953893/spelunky-most-important-game-of-the-decade-2010

I have tested it on a Rpi5, RaspiOS Lite 64bit with RetroPie-Setup -> Basic Install and the dev version of EmulationStation and also on a more crowded installation which uses some Retroarch emulators.

Please test and report back.

Notes:

Be aware that the setting kernel=kernel8.img is mandatory in /boot/firmware/config.txt.
Make sure to have a full backup of your current setup in the rare case something goes foobar.

Some Qs to the community:

As several extra armhf packages are installed, what is the "RetroPie way" for the remove function (remove_gmloader()): E.g. Remove them and also run a apt autoremove?
The scriptmodule pulls in the RetroPie compiled SDL2 libs, namely libsdl2-2.0-0_2.26.3+1rpi_armhf.deb and libsdl2-dev_2.26.3+1rpi_armhf.deb. I assume they are provided for a reason, or will the upstream packages do as well?

mitu

@Lolonois said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:

As several extra armhf packages are installed, what is the "RetroPie way" for the remove function (remove_gmloader()): E.g. Remove them and also run a apt autoremove?

In general, there's no removal of dependencies on package removal, since we can't know if that package is also used elsewhere.

The scriptmodule pulls in the RetroPie compiled SDL2 libs, namely libsdl2-2.0-0_2.26.3+1rpi_armhf.deb and libsdl2-dev_2.26.3+1rpi_armhf.deb. I assume they are provided for a reason, or will the upstream packages do as well?

Not sure what you mean, are you asking why your scriptmodule pulls some dependencies ? Isn't this coded in your scriptmodule already ?

Lolonois

@mitu said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:

[remove function of scriptmodule]

In general, there's no removal of dependencies on package removal, since we can't know if that package is also used elsewhere.

Ok. Makes sense.

[SDL2 libs from RetroPie vs Upstream]
Not sure what you mean, are you asking why your scriptmodule pulls some dependencies ? Isn't this coded in your scriptmodule already ?

It puzzles me as on a Pi4 there is the SDL2 lib package from RetroPie set on hold.
On a Pi5 with 64bit RaspiOS AFAIR the SDL2 scriptmodule installs also the 2.26.3+1rpi_arm64 (from sources). Thus I assumed this RetroPie SDL2 version is needed also on the Pi5/arm64 for some reason.

My question is like this then:
When a RetroPie SDL2 lib is found on a Pi5/arm64 do also install the counterpart on armhf?
-or-
Whatever version of SDL2 is installed (or even if it is absent), replace it with the one from the upstream package for arm64 and armhf?

mitu

@Lolonois said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:

On a Pi5 with 64bit RaspiOS AFAIR the SDL2 scriptmodule installs also the 2.26.3+1rpi_arm64 (from sources). Thus I assumed this RetroPie SDL2 version is needed also on the Pi5/arm64 for some reason.

On non-X11 platforms, RetroPie always tries to install its custom SDL2 version. You can bypass this if you want, but you'll be missing the kms bits which allow runcommand's resolution settings to propagate to SDL2 applications (emulators).
You can bypass this by setting own_sdl2=0 in retropie.cfg.

My question is like this then:
When a RetroPie SDL2 lib is found on a Pi5/arm64 do also install the counterpart on armhf?

Technically I don't think you'd be able to have different versions, one for each arch. But things are no so simple, see this issue and the discussion around it.

-or-
Whatever version of SDL2 is installed (or even if it is absent), replace it with the one from the upstream package for arm64 and armhf?

You override the install flag (own_sdl2) so you can use the distro's packages, but with the caveats explained above.

Lolonois

The gmloader uses the RP SDL2 libs and not the upstream ones.

I managed to get it properly working when either the RP SDL2 (arm64) libs are present or absent when installing gmloader. And also vice-versa.

However I noticed that the idempotence of the sdl2.sh scriptmodule is no longer given with multiarch and the libsdl2-2.0-0:armhf installed, e.g. it derails when run again after gmloader is installed with this message:

Unpacking libsdl2-2.0-0:arm64 (2.26.3+1rpi) ...
dpkg: error processing archive libsdl2-2.0-0_2.26.3+1rpi_arm64.deb (--install):
 trying to overwrite shared '/usr/share/doc/libsdl2-2.0-0/changelog.gz', which is different from other instances of package libsdl2-2.0-0:arm64

If I add these flag to dpkg the idempotence is restored with multiarch.

diff --git a/scriptmodules/supplementary/sdl2.sh b/scriptmodules/supplementary/sdl2.sh
index 861977c..ba7be8e 100644
--- a/scriptmodules/supplementary/sdl2.sh
+++ b/scriptmodules/supplementary/sdl2.sh
@@ -138,7 +138,7 @@ function remove_old_sdl2() {
 function install_sdl2() {
     remove_old_sdl2
     # if the packages don't install completely due to missing dependencies the apt-get -y -f install will correct it
-    if ! dpkg -i libsdl2-2.0-0_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb libsdl2-dev_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb; then
+    if ! dpkg -i -E --force-overwrite libsdl2-2.0-0_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb libsdl2-dev_$(get_pkg_ver_sdl2)_$(get_arch_sdl2).deb; then
         apt-get -y -f --no-install-recommends install
     fi
     echo "libsdl2-dev hold" | dpkg --set-selections

The --force-overwrite would overwrite changelog.gz and copyright in the /usr/share/libsdl2-2.0-0 folder.

Would it be ok to file a PR for the patch?

mitu

@Lolonois said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:

Would it be ok to file a PR for the patch?

I don't think so. Brute forcing is not a solution, but merely a workaround. How is Debian dealing with it ?

EDIT: Try adding

Multi-Arch: same

to the control file for the package (e.g. like https://salsa.debian.org/sdl-team/libsdl2/-/blob/debian/latest/debian/control?ref_type=heads#L55) and see if the multi-arch installation goes through without conflict errors.

Lolonois

@mitu Thanks. I have seen this flag. And it is unchanged from upstream. This is why I am scratching my head.

In the debian package it states (which gmloader downloads and installs):

$ LANG=C dpkg-deb -I libsdl2-2.0-0_2.26.3+1rpi_armhf.deb 
 new Debian package, version 2.0.
 size 445284 bytes: control archive=1040 bytes.
     657 bytes,    18 lines      control              
     527 bytes,     7 lines      md5sums              
      28 bytes,     1 lines      shlibs               
      68 bytes,     2 lines      triggers             
 Package: libsdl2-2.0-0
 Source: libsdl2
 Version: 2.26.3+1rpi
 Architecture: armhf
 Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org>
 Installed-Size: 1484
 Depends: libc6 (>= 2.34), libudev1, libdbus-1-3
 Conflicts: libsdl-1.3-0
 Replaces: libsdl-1.3-0
 Section: libs
 Priority: optional
 Multi-Arch: same
[...]

As well as in the sdl2.sh scriptmodule the control file is not altered in this aspect and uses Multi-Arch: same from upstream. The (pre)installed version reflects this also:

$ aptitude show libsdl2-2.0-0:arm64=2.26.3+1rpi
Package: libsdl2-2.0-0                   
Version: 2.26.3+1rpi
State: installed
Automatically installed: no
Multi-Arch: same
Priority: optional
Section: libs
Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org>
Architecture: arm64
Uncompressed Size: 1,834 k
Depends: libc6 (>= 2.34), libudev1, libdbus-1-3
Conflicts: libsdl-1.3-0
Breaks: libsdl2-2.0-0:armhf (!= 2.26.3+1rpi)
Replaces: libsdl-1.3-0, libsdl2-2.0-0:armhf (< 2.26.3+1rpi)
Description: Simple DirectMedia Layer
 SDL is a library that allows programs portable low level access to a video framebuffer, audio output, mouse, and keyboard. 
 
 This package contains the shared library, compiled with X11 graphics drivers and OSS, ALSA and PulseAudio sound drivers.
Homepage: http://www.libsdl.org/
Tags: role::shared-lib

The only thing which may be odd is the Replaces: libsdl-1.3-0, libsdl2-2.0-0:armhf (< 2.26.3+1rpi). But as the version comparator for libsdl2-2.0-0 is "less" than and not "less or equal" it should not have an effect.

(NB: the same can be seen on the armhf package:

$ aptitude show libsdl2-2.0-0:armhf=2.26.3+1rpi
Package: libsdl2-2.0-0:armhf             
Version: 2.26.3+1rpi
State: installed [held]
Automatically installed: no
Multi-Arch: same
Priority: optional
Section: libs
Maintainer: Debian SDL packages maintainers <pkg-sdl-maintainers@lists.alioth.debian.org>
Architecture: armhf
Uncompressed Size: 1,520 k
Depends: libc6:armhf (>= 2.34), libudev1:armhf, libdbus-1-3:armhf
Conflicts: libsdl-1.3-0
Breaks: libsdl2-2.0-0 (!= 2.26.3+1rpi)
Replaces: libsdl-1.3-0, libsdl2-2.0-0 (< 2.26.3+1rpi)
[...]

mitu

@Lolonois I'll take a look to see what can be done for the packages to be installable in this - multi-arch - scenario. Upstream packages have the same files included, but there's no conflict (I assume, haven't tried it so far).

Lolonois

Thanks. But handle it with lower priority, as the gmloader is not a official RetroPie package and this issue only shows when sdl2 from RP is present before gmloader is installed and then it is tried to reinstall the sdl2 after gmloader is installed.

Workaround for anyone stumbles about this:

Remove libsdl2-2.0-0:armhf. sudo apt remove libsdl2-2.0-0:armhf
Remove sdl2: sudo RetroPie-Package/retropie_packages.sh sdl2 remove
Remove potential leftovers: sudo rm -f /usr/share/doc/libsdl2-2.0-0/copyright /usr/share/doc/libsdl2-2.0-0/changelog.gz
Install sdl2 again: sudo RetroPie-Package/retropie_packages.sh sdl2
Run gmloader script again to get back libsdl2-2.0-0:armhf. sudo RetroPie-Package/retropie_packages.sh gmloader

mitu

@Lolonois I've tried to see where is the problem on an multi-arch installation and check whether this is a packaging issue for the SDL2 packages we create. From what I can see, the packaging is ok, the thing is you need to have both packages at the exact same version and built using the same source.

I've build - on a clean env - 2 arch packages from RetroPie's SDL2 sources and they can be co-installed on the same system:

mitu@host:~/src/sdl.mine[cross]$ dpkg --print-architecture
amd64
mitu@host:~/src/sdl.mine[cross]$ uname -r
6.10.11-amd64
mitu@host:~/src/sdl.mine[cross]$ uname -m
x86_64
mitu@host:~/src/sdl.mine[cross]$ dpkg --print-architecture
amd64
mitu@host:~/src/sdl.mine[cross]$ dpkg --print-foreign-architectures
i386
mitu@rockman:~/src/sdl.mine[cross]$ dpkg -l | grep libsdl2-2.0-0
ii  libsdl2-2.0-0:amd64                  2.30.8+rpi6                       amd64        Simple DirectMedia Layer
ii  libsdl2-2.0-0:i386                   2.30.8+rpi6                       i386         Simple DirectMedia Layer

It was easier to set-up a cross-build env on a PC, but I don't think things are different for the arm64/armhf combo.

Lolonois

@mitu Thanks for digging this up. I will remember it when I am about to fix this.