lr-flycast: Issue with source (likely from upstream change)

roslof

Raspberry Pi 4B/4GB; Retropie 4.5.18
unsupported Pi4B but probably unrelated

Just a heads-up that using lr-flycast from current source will result in a segfault for Dreamcast, Naomi & Atomiswave games.

Possibly related to a recent VRAM change made upstream

From tail of /dev/shm/runcommand.log:

[libretro INFO] 00:03:922 rend/gles/gles.cpp:414 N[RENDERER]: OpenGL version: (null)
[libretro ERROR] 00:03:922 libretro/common.cpp:376 E[COMMON]: SIGSEGV @ b4e54ab0 ... (nil) -> was not in vram (dyna code 0)
[libretro INFO] Fatal error : segfault
 in signal_handler -> core/libretro/common.cpp : 383

[libretro ERROR] 00:03:922 libretro/libretro.cpp:3230 E[COMMON]: DEBUGBREAK!
[libretro ERROR] 00:03:922 libretro/common.cpp:376 E[COMMON]: SIGSEGV @ acef3e40 ... 0xacef3e40 -> was not in vram (dyna code 0)
[libretro INFO] Fatal error : segfault
 in signal_handler -> core/libretro/common.cpp : 383

Current work-around is to install from pre-built binary. Will look into this a bit more when I have a chance, building from earlier commits.

roslof

Spotted a thread regarding the issue:

flycast no longer works using the gles renderer? #851
https://github.com/libretro/flycast/issues/851

BuZz

Looking into it. Thanks.

roslof

Np.

Confirmed that the offending commit is 4cf6c1f [Switch] Initial Port
The prior commit to master dd4f35d Protect ram and vram when vmem is disabled works fine.

BuZz

@roslof I bisected to the same commit. But then I got the latest code running. Suspect it may have been due to make clean not removing all objects but I'm checking my changes again.

BuZz

Please can you build the latest code but set HAVE_LTCG=0 in the makefile or via the RetroPie module script.

I think link time optimisation fails after that commit so it should be enough to just disable it. I'm just verifying.

mitu

@BuZz Seems to work after that option is added

 function build_lr-flycast() {
-    local params=()
+    local params=(HAVE_LTCG=0)
     make clean
     if isPlatform "rpi"; then
         if isPlatform "rpi4"; then

BuZz

I'll commit the change. Maybe someone else can update the referenced ticket upstream (short on time). The ticket is another issue I think but might be worth clarifying the cause for the RPI issue.

BuZz

It's could also be due to missing parameters at link time which are needed if using lto. I'm doing a test now, but the Makefile is a bit of a mess really and I don't think it's well tested with lto for most platforms, so it's better to leave it disabled.

Eg. I previously added an LDFLAGS+=$(CFLAGS) as it was generating armv6 code with lto enabled as it just used LDFLAGS and missed out all the cpu flags.

roslof

Updated the script. Works as you'd expect. Thanks BuZz & mitu!