Compiler error on Ubuntu for Nintendo Switch about box86 HOT 8 CLOSED

There is no 32bits drivers on the L4T. box86 can be built on AArch64 with multiarch or chroot, but the lack of opengl driver will make the build pretty useless.
Closing the ticket.

from box86.

be sure to build for 32 bits, box86 will not run on 64bits system for now. Probably need to -m32 ? Also maybe force the use of ARM in case Thumb is default (with -marm). No idea if that ubuntu for switch is a 32 or 64 bits (or both), and the link you provide doesn't mention that.
Basically that's a gcc internal error, were the assembler cannot build the code generated by gcc (maybe some missing -mcpu=XXXX somewhere? no real idea ).

from box86.

I've been playing around with Switch L4T and it's an arm64 platform so I haven't really messed with box86 on it. My Rock Pi is also a 64-bit platform but the default Debian build is 32-bit and box86 works on that. I just tried:

cmake -m32 ..

on my Switch and it gives an error:

/home/adam/box86/src/x86syscall.c:195:31: error: storage size of 'st' isn't known

Also:

error: '__NR_stat64' undeclared

It doesn't look like this will build on a 64-bit OS. Maybe I'll try debootstrapping a 32-bit chroot, but apparently the Tegra GPU drivers aren't available for 32-bit.

Edit: It does build and run in a chroot, but I haven't tested graphical apps yet. Command line apps work.

from box86.

Any update on the functionality of Box86 running graphical apps on Switch?

from box86.

Box86 will never work on 64bits as is (that will be another projet, probably named box86_64, but that will run only x86_64 binaries). You need to have 32bits drivers / chroot to use Box86 on a 64bits system.

from box86.

I got box86 to compile on the Nintendo Switch by using an armhf chroot but it looks like Nvidia only provide 64-bit OpenGL drivers for tegra so games won't run anyway

from box86.

Nvidia only provide 64-bit OpenGL drivers for tegra so games won't run anyway

VirGL could be used to pipe OpenGL between Mesa in a 32-bit box86 process and a 64-bit rendering server:

https://gitlab.freedesktop.org/virgl/virglrenderer

https://www.collabora.com/news-and-blog/blog/2019/08/28/virglrenderer-state-of-virtualized-virtual-worlds/

To get the window contents back to the client process VirGL uses ReadPixels, so performance is terrible, but if a window is created in the server process and that is made visible while input is still passed to the window from the client process, then performance should be more acceptable.

from box86.

@icecream95 Is right. Kreal form PiLabs Discord done this setup for me on my Jetson Nano. It's working, with huge bottleneck on software side (we used Xephyr as display, couldnt get it to work form chroot on host display). World of Warcraft: Wrath of the Lich King and Gothic was working at ~20 FPS, but CPU usage was low and GPU was max at 40% usage 250 MHz. Probably another options to have true armhf GPU acceleration on L4T devices is patching old L4T 24.1 kernel and drivers, waiting for future updates to nouveau, usage of libhybris to use Android armhf drivers form Shield TV devices or Android builds for Switch. As Jetson Nano don't have working Android version, I can't even try last one.

from box86.