mirror of
https://github.com/libretro/Mu.git
synced 2026-02-13 05:35:02 +00:00
Loading a prc file does not install correctly #21
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SinnohConfirmed on GitHub (Jul 16, 2025).
When loading a prc file or a zip file containing a prc file in Mu it does not install anything to RAM. Instead, it boots to the welcome screen that one would get when launching the core without any content. No software is installed. Currently it seems the only way to load software is to load an SD card image.
I installed an older version of this core from an older Retroarch release and found that loading prc files works correctly. Version 1.3.1
865acf3from Retroarch 1.19.1 is the last version that works. Retroarch 1.20.0 has Mu 1.3.2e5829b6, and this version won't install prc files correctly. Launching a prc in 1.3.1865acf3and generating a RAM file, then loading this prc in the latest Mu version also works.This was done on Windows 11 with Retroarch 1.21.0 with a Palm OS 4.1P m515 ROM. All older versions of the core were loaded with this version of Retroarch. I have also experienced this issue on Android and SteamOS.
@XerTheSquirrel commented on GitHub (Jul 16, 2025):
Have you been able to try Mu 1.3.3?
@SinnohConfirmed commented on GitHub (Jul 16, 2025):
Yes, with Mu 1.3.3 from Retroarch's Core Downloader I still have this issue. This is only an issue when generating a new .ram file on versions 1.3.2 and 1.3.3. If I load a prc in Mu 1.3.1 and generate a new .ram file and then load the prc on 1.3.3 with this .ram file everything works as expected.
@XerTheSquirrel commented on GitHub (Jul 17, 2025):
Will have to look into this, perhaps RAM generation broke although I have not made any changes surrounding that at all.
@natanprog commented on GitHub (Aug 11, 2025):
Hi — thanks for maintaining this core!
I originally reported the problem on Discord here:
https://discord.com/channels/517858466686304257/522934434564014081/1372307493388030003
I traced the regression to commit
dee65d0which changed libretroBuildSystem/libretro.c. The change removed/relocated the hasSram = true; assignment from inside the if (saveRamFile) branch. Reverting that single line (restoring hasSram = true; to the previous location) makes the core behave like it did before — PRC files are installed into RAM again on my tests.I don’t fully understand all the consequences of this change, but toggling that line consistently fixes the issue for me.
Thanks!
@XerTheSquirrel commented on GitHub (Aug 11, 2025):
Thanks for the bisect! I have not had the time the past month or so to look into this deeply, but I will look into this now! Thank you!
@XerTheSquirrel commented on GitHub (Aug 11, 2025):
This should be fixed now, hopefully, I have tested it. Please do confirm once you are able to get the new version from buildbot in a few hours generally, barring any buildbot issues.
@SinnohConfirmed commented on GitHub (Aug 13, 2025):
Thanks for the fix :)
It looks like the buildbot still has a build from commit
acc2107, so I'm not able to test it right now. I'll keep an eye out for when it has a build for the latest commit.@zoltanvb commented on GitHub (Aug 14, 2025):
The buildbot fails to build for some old Windows platforms, with error:
libretro.obj : error LNK2019: unresolved external symbol _alloca referenced in function _sleepAnimationhttps://git.libretro.com/libretro/Mu/-/pipelines
@zoltanvb commented on GitHub (Aug 16, 2025):
I see it is fixed, and at least for Linux the correct version is now on the buildbot.
@SinnohConfirmed commented on GitHub (Aug 16, 2025):
Yep, I was able to grab the latest build from the buildbot and the bug is fixed! I tested on Windows, Flatpak and Android, all were able to load a .prc file just fine.
Thanks everyone!
@XerTheSquirrel commented on GitHub (Aug 17, 2025):
Awesome, happy to hear! The
allocaunresolved was specifically for MSVC as it does something different, everything else uses GCC.