Are there any plans to support the ARM64 architecture? 64-bit OSes for the Raspberry Pi and other boards are becoming more popular, and at present the only way to run PICO-8 on a 64-bit Pi OS is to install Raspbian in a chroot, use a hack in the .Xauthority file, and run PICO-8 from within the chroot.
That is not a satisfactory solution. No OSes exist for the Pi that have a mixed userland (Raspbian is 32-bit only) so the most practical solution is to put together an ARM64 build for PICO-8.
If you don't have easy access to a 64-bit image to build on, there is one based on Gentoo that comes with a desktop and toolchain out of the box: https://github.com/sakaki-/gentoo-on-rpi-64bit
Only you have the source code, @zep! What do you think? :P
+1, now that I know this is an issue anyway. There's also a usable image of Ubuntu Server here:
I think the latest official distro of 19.10.x is fairly complete in its support for RPi4 in arm64 mode too, but I haven't tried it myself yet.
I did some digging. Distros that enable 32-bit support in the kernel for their ARM/RPi builds should be able to run a 32-bit static binary without a 32-bit userland.
I also noticed that both pico8 and pico8_dyn are dynamically linked in the pi download. The former is stripped, but not static. So the hardware may support it, but the binary wasn't built statically, so it looks for the 32-bit armhf loader, which won't work on an aarch64 userland without building a multilib system (of which nobody does at the time of writing due to 32-bit ARM arch fragmentation and the looming 2038 problem).
So, fixing it to be static can be a good interim solution while aarch64 is being looked into. It would at least give us a way to run it in a 64-bit userland.
While I did this I checked the x86_64 version of PICO-8 and both ./pico8 and ./pico8_dyn are dynamically linked there, too:
$ readelf -d ./pico8 Dynamic section at offset 0x24fa50 contains 28 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x403680 0x000000000000000d (FINI) 0x5d9894 0x0000000000000019 (INIT_ARRAY) 0x84e150 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x84e158 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x400298 0x0000000000000005 (STRTAB) 0x401720 0x0000000000000006 (SYMTAB) 0x4002e0 0x000000000000000a (STRSZ) 2113 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x851000 0x0000000000000002 (PLTRELSZ) 4992 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x402300 0x0000000000000007 (RELA) 0x402228 0x0000000000000008 (RELASZ) 216 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x402118 0x000000006fffffff (VERNEEDNUM) 5 0x000000006ffffff0 (VERSYM) 0x401f62 0x0000000000000000 (NULL) 0x0
readelf -d ./pico8_dyn Dynamic section at offset 0x114dc8 contains 26 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libSDL2-2.0.so.0] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x4035f0 0x000000000000000d (FINI) 0x4dc454 0x0000000000000019 (INIT_ARRAY) 0x713fd0 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x713fd8 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x400298 0x0000000000000005 (STRTAB) 0x401668 0x0000000000000006 (SYMTAB) 0x4002e8 0x000000000000000a (STRSZ) 2696 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x715000 0x0000000000000002 (PLTRELSZ) 4680 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x4023a8 0x0000000000000007 (RELA) 0x402330 0x0000000000000008 (RELASZ) 120 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x402290 0x000000006fffffff (VERNEEDNUM) 2 0x000000006ffffff0 (VERSYM) 0x4020f0 0x0000000000000000 (NULL) 0x0
(Perhaps I'm misunderstanding the intended distinction between pico8 and pico8_dyn.. clarification would be appreciated)
Can't really comment on the ABI details as I don't know the arm platform at all, but (and I should really get off my butt and check this stuff for myself but I don't have much time at the moment) I remembered that Ubuntu 19 also supports KVM, if you can live with virtualization that may be another interim option.
Also thanks Felice, I wasn't thinking of stars as +1's (more like bookmarks), but I've clicked the appropriate places now.
@Catatafish: It should really only be an addition of a build target in whatever build system @zep uses to build PICO-8. AFAIK every major build system supports aarch64. Then (maybe) a change to how 'pico8' gets built so it produces a static binary. We'd run into fewer linking issues because customers could fall back to the static binary if there's an issue with their system.
The devil's in the details: it adds to the maintenance burden (if only a little) and it's another build target to test, another download link, etc. Maybe it's not a problem, since the PocketCHIP still gets PICO-8 builds and it's dead hardware. (not meant as a pejorative; they look fun and it's a shame it's not a thing anymore)
EDIT: I hear you on time constraints! So many things I want to do in PICO-8, never enough time. :)
Bumping to mention that Raspberry Pi recently announced a split from the Raspbian name (but still using the same base) and released an official 64-bit port, to give users access to the full 8GB (!) available on the brand-new Pi4B.
When my pinebook pro comes in, I intend to try various experiments to see if I can get the stock x86 pico-8 binary running.
I don't have particularly high hopes for Box86. I'm pretty sure I can get qemu to work but I expect the performance to be super abysmal. We'll see.
Can't blame @zap for not wanting to build binaries for all the new ARM devices, there are so many and they each require custom support for their various graphics chipsets (Kind of a design downside for the architecture IMO)but that won't stop me from trying :)
I'll report back here should I have any success, or if I end up giving up entirely :)
[Please log in to post a comment]