Retropie SDL2 apt packages on ARM64 break multiarch
theofficialgman opened this issue · 4 comments
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:
- if host dpkg architecture arm64 and the user has armhf dpkg foreign architecture already enabled, install both armhf and arm64 matching updated SDL2 packages.
- 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.
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.
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 installingarm-linux-gnueabihf-gcc
- You need to edit
scriptmodules/supplementary/sdl2.h
to update thedpkg-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 uninstallfcitx-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 editeddebian/control
to remove the linefcitx-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 editscriptmodules/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.
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.
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
.