[SOLVED] Error in detecting cores i.e. error opening file

RetroArch Linux devices
#1

Hi all,

New to forums, so I think I’m in an ok place, but let me know if I’m not. I am running Retroarch 1.10.3 on Raspbian 64-bit, and I’ve grabbed the package from Flatpak (using the most basic commands found here). The program compiles, and after configuring the directories in setting to point at the appropriate folders generated (and altering the config to grab the latest cores found for Linux x86_64 systems found here), the core updater pulled the files into the appropriate folder, and I updated all other fields which could be (Cheats, Overlays, Core Info, etc.).

Then, the dreaded news came, and the most generic issue cited on RetroArch’s FAQ page: " When I try to load a core, RetroArch still says No Core". The only listed option under this FAQ which seemed to make sense was to generate a log file, to try and sniff out the errors (lines 54-63 in this gist). Esoteric advice online seems to regard it as an issue with shared libraries, which usually points at /lib, /usr/lib, and /usr/local/lib, but Flatpak installed everything in /var/…/, so I’m wondering if the fix is there. In the GUI, I can see my downloaded cores in the Load Core screen, but after selecting one, it still says No Core in the bottom right-hand corner.

I’m hoping we can figure this out together; if any extra info is needed, let me know.

Retroarch config gist: file two in log gist

#2

by Raspbian, I’m assuming you’re on a Raspberry Pi or similar SBC (i.e., running an ARM CPU)? If so, the x86_64 cores will not work. Cores need to be compiled for the appropriate architecture.

Our buildbot does not produce ARM linux binaries, but I have quite a few popular cores compiled for aarch64 linux here: https://github.com/hunterk/libretro_builds

1 Like
#3

@hunterk This is correct, it’s a Raspberry Pi 400; appreciate the quick response. I have confirmed this works for Snes9x and PCSX-ReARMed, and although Mupen fails to load content, the core is recognized. I’ll keep an eye on that repository, and look forward to cores being added and fixed in the future; thanks!

#4

Can you give me the error that mupen spits out? (that is, post a verbose log of it trying and failing to load stuff)

I have no way of testing these cores myself, so any logs you can provide for them is helpful.

#5

Certainly @hunterk; I updated the public gist with the log file from loading the core, then attempting to boot three different ROMs (file is retroarch.log (1)).

I’d be happy to try out others (especially the mGBA if it ever passes, as that gets GB, GBC, and GBA out of the way for me).

#6

mGBA passed, I just forgot to add it to the README matrix: https://github.com/hunterk/libretro_builds/releases/download/Linux_aarch64/mgba_libretro.so.zip

Can you link me to the gist(s)?

#7

Here is the link.

#8

Ah, perfect. Thanks!

It looks like it’s failing to create the GLES2 context because RetroArch is using desktop OpenGL. Is that correct?? I thought these mobile chipsets all used GLES…

[ERROR] Requesting OpenGLES2 context, but RetroArch is compiled against OpenGL. Cannot use HW context.

[ERROR] [Environ]: SET_HW_RENDER - Dynamic request HW context failed.
#9

This forum looks like it might answer your question in regards to OpenGL vs. OpenGLES on Raspberry Pi 3 vs 4.

Looks like mGBA is working for a GB, GBC, and GBA ROM; if any don’t work, I’ll reupdate here.

1 Like
#10

Can you try this build? https://github.com/hunterk/libretro_builds/releases/download/Linux_aarch64/mupen64plus_next_libretro_NO-GLES.zip

#11

Log can be found here under file retroarch.log (2), @hunterk . Line 204-205 show where the error occured, and it was so fatal all of RetroArch crashed.

#12

looks like it’s trying to use glcore but doesn’t have high enough support (core needs 3.3; based on that aforementioned thread, rpi4 has only up to 3.1).

Did you compile the flatpak yourself? If so, can you try compiling it with GLES support instead of desktop GL? That would let you use the regular GLES version (though I might need to spin up a GLES3 version then… we’ll see).

#13

If you’re asking if I downloaded the pack from here and compiled @hunterk , I did not. I added from the remote repository via Flathub using the instructions given here; truth be told, I don’t have a lot of experience compiling programs from source, I usually go with package managers, so centralized version updating for programs I have installed is quicker and easier (even if repositories managed this way aren’t ALWAYS the most up-to-date).
That said, if I had relative guidance on how to compile from source a Flatpak (w/ the specialized instruction of designating the different OpenGL version), I’d probably be willing to give it a go.

#14

ok, no problem. I’ll try to talk to RobLoach who maintains the flatpak and see if there’s anything we can do about it on our end.

1 Like