Raspberry-Pi-OS-64bit
Raspberry-Pi-OS-64bit copied to clipboard
Unable to install librasperrypi0:armhf as it conflicts with arm64 version
Unable to install librasperrypi0:armhf as it conflicts with arm64 version
It is required for running armhf apps like Box86 and more
The README there says: "You NEED a 32-bit subsystem to run and build Box86. Box86 is useless on 64-bit only systems. Also, you NEED a 32-bit toolchain to build Box86. A toolchain that only supports 64-bit will not compile Box86, and you'll get errors (typically on aarch64, you get "-marm" not recognized, and you'll need a multiarch or chroot environnement)." so it sounds like it'll be easier to stick with 32-bit Raspberry Pi OS for running that?
I'm guessing that's getting dragged in by libsdl. Hopefully that won't be an issue in Bullseye once that's released.
@lurch Debian based systems generally provide cross-compilers and ability to run programs for cases like this. In theory, this should work, it's just that our packages weren't initially set up with multiarch in mind. Bullseye should be a bit better. I haven't tried it yet, but such issues should at least be fixable now.
But yes, stick with 32-bit for now.
The README there says: "You NEED a 32-bit subsystem to run and build Box86. Box86 is useless on 64-bit only systems. Also, you NEED a 32-bit toolchain to build Box86. A toolchain that only supports 64-bit will not compile Box86, and you'll get errors (typically on aarch64, you get "-marm" not recognized, and you'll need a multiarch or chroot environnement)." so it sounds like it'll be easier to stick with 32-bit Raspberry Pi OS for running that?
I use multiarch as mentioned here and it works fine on ubuntu arm64.
The only issue i have caught so far is that I cannot install librasperrypi0:armhf with multiarch enabled with sudo dpkg --add-architecture armhf
.
As a result all the libraries that depend on librasperrypi0 fail to install
Thanks for quick response.
@XECDesign The issue is already fixed in RPiOS Bullseye but still is an issue in Buster.
This should also be fixed in arm64 and armhf buster libraspberrypi0 package by adding Multi-arch: same
to its control file, as still many people use buster as their daily driver
Buster is now our Legacy OS release (more info here), and so I suspect this "fix" won't be backported to there?
I have seen that already, but isn't buster still getting some updates... If yes then this fix is worth an update
Buster is only getting major bug fixes and security patches.
But the libraspberrypi0 is still getting updated so this can be easily fixed