Retropie SDL2 apt packages on ARM64 break multiarch

[theofficialgman]

Retropie setup installs a custom updated SDL2 which helps with compatibilty with retropie emulators. However this version does not have a matching armhf version installed alongside it. This causes breakage when the user goes to install armhf SDL2 like is common in multiarch scenarios.

It would be good to do two things to solve this:

1. if host dpkg architecture arm64 and the user has armhf dpkg foreign architecture already enabled, install both armhf and arm64 matching updated SDL2 packages.
2. create a local repository on the users system with SDL2 armhf and arm64 packages so that if the user does not have armhf dpkg foreign architecture enabled but does enable it later, the updated armhf package can be installed from the local repo.

As it is right now, the user will be met with errors such as this

The following information may help to resolve the situation:
The following packages have unmet dependencies:
 libsdl2-dev : Depends: libsdl2-2.0-0 (= 2.26.3+1rpi) but it is not installable
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
Apt finished.

which may lead them to uninstall sld2 alltogether from their system.

[cmitu]

The 3rd option, which we used before on x86/x86_64 multiarch, is to disable RetroPie's own SDL2 packages and use the package(s) provided by the distribution.

[GeorgeMcMullen]

I've done a little research in getting SDL2 for armhf installed on a multiarch system, and it's a bit of a pain. I don't currently see how RetroPie will be able to support multiarch environments without an architectural level change. Here are my notes so far though. Your mileage may vary based on the SBC you are using and the base OS.

• Basics are dpkg --add-architecture armhf and installing arm-linux-gnueabihf-gcc
• You need to edit scriptmodules/supplementary/sdl2.h to update the dpkg-buildpackage line to be: PKG_CONFIG_PATH= dpkg-buildpackage -b --host-arch armhf
• You also need to edit scriptmodules/supplementary/sdl2.sh and adding :armhf to all of the depends
• FIRST DANGER: Some fcitx libs can't have different architectures coexist with eachother. So installing fcitx-libs-dev:armhf may uninstall fcitx-libs-dev:arm64. This may happen with other libraries you have installed.
• The first time you build you may get a message stating that it can't compile because of a missing fcitx-libs-dev in this case, I edited debian/control to remove the line fcitx-libs-dev [linux-any],
• You may get other compilation errors, for example my arm-linux-gnueabihf-gcc didn't accept the option -march=native so I had to edit scriptmodules/system.h to change my cflags accordingly.
• SECOND DANGER: If compilation is a success, you may still have trouble installing because the following files might be different in between armhf and arm64. I'm not sure why some of them are, since they are from the same source. Others, just seem to have minor changes. In all, I didn't find any harm in just moving them to force the install. Not a long term solution though.

/usr/share/doc/libsdl2-2.0-0/changelog.gz 
/usr/bin/sdl2-config
/usr/share/doc/libsdl2-2.0-0/copyright
/usr/include/SDL2/SDL_config.h
/usr/share/doc/libsdl2-dev/changelog.gz
/usr/share/doc/libsdl2-dev/examples/examples.tar.gz

The benefit of doing this is that you have the same modifications to SDL2 on both 32bit and 64bit. It also allows me to use v2.26.3 rather than v2.0.10. I tried looking for backports or updates of SDL2 v2.26.3 for armhf, but wasn't able to install them because of even further issues like libc6 requirements that would have required even more updates to the OS. I'm still testing, so not sure how well everything will work. I'll post an update if I find anything new.

[theofficialgman]

No no no....
It's not hard at all. Just build the Deb on an armhf only system. Then the resulting Deb can be installed on armhf only systems or arm64 with armhf multiarch. No changes necessary at all.
I know this because that's what I have been doing the whole time. See my debs here https://github.com/cobalt2727/L4T-Megascript/tree/master/assets/SDL2 armhf devs created in armhf Ubuntu bionic chroot, arm64 debs created in an arm64 Ubuntu bionic chroot. Both using the same source so zero conflicts.

[GeorgeMcMullen]

You're right, that is definitely another option. Your packages are awesome and helpful. Thanks for sending the link.

My own purposes though was to be able to build and install completely from a multiarch system. I had considered building from an armhf system, but only had an arm64 system running at the time (and it's not a Raspberry Pi). So I opted to be lazy and do the harder thing; strange, I know. LOL.

As for the conflicts, as I say, your mileage may vary. I'm still investigating why those existed for me. Everything was built from the same source. I may just clean out the system and start from scratch as I had experimented with MANY different things as I was doing this. Files like sdl2-config I can see where the differences are, but the changelog and examples should really have no changes.

Regardless, even with precompiled binaries, it would be good if RetroPie could detect multiarch and then install (and/or compile) the appropriate binaries as necessary. Much like how one can with apt by adding :armhf or :arm64 after the package name. Something like sudo ./retropie_packages.sh sdl2:armhf install.