Add support Linux ARM64

[beudbeud]

When i try to cross building for rpi5 i have error when i need compile CPU 68K

++: error: unrecognized argument in option '-mabi=lp64'
g++: note: valid arguments to '-mabi=' are: ms sysv
g++: error: unrecognized argument in option '-mabi=lp64'
g++: note: valid arguments to '-mabi=' are: ms sysv
g++: error: unrecognized argument in option '-mabi=lp64'
g++: note: valid arguments to '-mabi=' are: ms sysv
g++: error: unrecognized argument in option '-mabi=lp64'
g++: note: valid arguments to '-mabi=' are: ms sysv
make[2]: *** [Makefile:91: Src/CPU/PowerPC/PPCDisasm.o] Error 1
make[2]: *** Waiting for unfinished jobs....

[beudbeud]

do you think there are way for make the core work on OpenGLES on Linux?

[sgiannop]

beudbeud, apologies for the delay. I’ve been refactoring the build system to address these issues.

The ABI Error: The -mabi=lp64 error occurred because the previous Makefile was attempting to pass x86-specific flags to the ARM compiler. I have implemented a dedicated Makefile.rpi64 using the aarch64-linux-gnu- toolchain which resolves the CPU (68K/PPC) compilation failures.

GLES Support: Yes, I have successfully ported the core to OpenGLES 3.0. I've integrated a new symbol loader (glsym_es3.c) and resolved the header collisions between the system GLES headers and the internal Model 3 shaders.

I am pushing the fix now. You will be able to build for RPi5/ARM64 using the new target.

[sgiannop]

Reopening this issue to allow for community testing. While the AArch64 toolchain and GLES3 fixes are now merged, I want to ensure the -mabi errors are fully resolved on various RPi5 environments before officially closing.

[beudbeud]

So nice I will try that when I will be at home

[beudbeud]

after to find the right configuration for crosscompile it with buildrooot i cant start core on rpi5

[INFO] === Build =======================================
[INFO] Capacités: ASIMD
[INFO] Version: 1.21.0
[INFO] Built: Mar  4 2026
[INFO] =================================================
[INFO] [Input]: Found input driver: "udev".
[INFO] [Core]: Loading dynamic libretro core from: "/usr/lib/libretro/supermodel_libretro.so"
...
[INFO] [Content]: Chargement du contenu ignoré. L'implémentation va le charger elle-même.
[INFO] [CONTENT LOAD FILE] Got CRC32 from command line: 0x0 .
[INFO] [Environ]: SET_HW_RENDER, context type: gl.
[ERROR] Requesting OpenGL context, but RetroArch is compiled against OpenGLES. Cannot use HW context.
[ERROR] [Environ]: SET_HW_RENDER - Dynamic request HW context failed.
[libretro ERROR] [Supermodel] HW Render Context negotiation failed.
[ERROR] [Content]: Échec de chargement du contenu.
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 00 seconds.
``

[beudbeud]

surely because of this line
https://github.com/sgiannop/Libretro-Supermodel/blob/0f0208c1b28f345a394a6e7db17836d7996ac0f8/Src/OSD/libretro/libretro.cpp#L159

in Makefile.rpi64 there arent HAVE_GLES but -DHAVE_OPENGLES=1 -DHAVE_OPENGLES3=1

[beudbeud]

After force HAVE_GLES=1 in makefile i have this error

Error: Vertex shader failed to compile. Your OpenGL driver said:
0:1(10): error: GLSL 4.10 is not supported. Supported versions are: 1.00 ES, 3.00 ES, and 3.10 ES

Error: Fragment shader failed to compile. Your OpenGL driver said:
0:1(10): error: GLSL 4.10 is not supported. Supported versions are: 1.00 ES, 3.00 ES, and 3.10 ES

Error: Failed to link shader objects. Your OpenGL driver said:
error: linking with uncompiled/unspecialized shadererror: linking with uncompiled/unspecialized shader```

[sgiannop]

@beudbeud, you're right, the Makefile was using HAVE_OPENGLES while the code expects HAVE_GLES.
I'll normalize this in the next push.

Regarding the shader headers, seems the RPi5 is strictly GLES 3.x, so it's rejecting the Desktop GLSL 4.10 headers.
I need to update the shader strings to use #version 300 es, and add the required precision qualifiers for the mobile stack.

Hang tight—I'll push a fix to address the shader versioning for AArch64/GLES targets specifically!
excellent debugging!

[beudbeud]

i tried to force #version 300 with #if defined(ANDROID) || defined(HAVE_GLES) everywhere i find it in code but i have problem with LoadShaderProgram function i still have error when build shader

[sgiannop]

@beudbeud, I suspect the compiler is failing because GLES 3.0 is very strict. Two things are likely missing:
The 'es' suffix: It must be #version 300 es, not just #version 300.
Precision Qualifiers: GLES fragment shaders require a line like precision highp float; at the very top.

I'm currently refactoring the LoadShaderProgram logic to inject these headers dynamically when HAVE_GLES is defined.
If you want to try a 'dirty fix' to verify, try prepending those two lines to the shader strings before they hit the compiler.

[beudbeud]

Yes sure I can try a fix, can you send me a patch

[beudbeud]

i patch and game start but run at 30fps on rpi 5 :(