After the last update of Retropie for RP4 - Could not successfully build lr-flycast

rejesterd

Just noting that I was able to update flycast from source just a moment ago. No build errors this time.

davidgrohl

@rejesterd said in After the last update of Retropie for RP4 - Could not successfully build lr-flycast:

Just noting that I was able to update flycast from source just a moment ago. No build errors this time.

Great mate. I’ll try as soon as I can!

rejesterd

@BuZz @Darksavior The flycast update completed successfully today, but now it doesn't load my .chd games like it did before. I didn't test much further before reverting to my working clone from last week, but this is from my original flycast build log from Feb 8th:

git clone --recursive --depth 1 --branch master "https://github.com/libretro/flycast.git" "/home/pi/RetroPie-Setup/tmp/build/lr-flycast"
Cloning into '/home/pi/RetroPie-Setup/tmp/build/lr-flycast'...
HEAD is now in branch 'master' at commit 'fb7d27704bfef725638dd55bc8481456b47aa671'

That's a known working version that can load chd files.. so before the texture-related changes went in, it looks like.

tackett1980

Ok I tried again and got no errors.

I changed nothing I just tried again.

roslof

@rejesterd yeah, I can confirm that rebuilding older versions that used to play nicely with CHDs won't launch CHD games for me either. The "bus error" still appears in the log. Couldn't find much info on that.

It's like some library or configuration file changed and the issue is not build-specific. Trying to learn more, but couldn't find anything unusual in the roms directory, configs/dreamcast, nor opt/retropie/libretrocores directories. Full removal and rebuild yields the same issue.

BuZz

Upstream builds again so I'll be updating the module after testing. The CHD issue could be related to some changes I made so I'll recheck that also.

roslof

@BuZz yeah, I had just figured it out -- Something to do with the recent change to the lr_flycast.sh changes that reference scriptmodules/libretrocores/lr-flycast/01_flags_fix.diff . I reverted to previous lr_flycast.sh and was able to build/run with the latest upstream build.

Appreciated, as always.

BuZz

@roslof yep. previously we were generating armv6 code due to our CFLAGS not being passed during link time optimisation. Lto can be buggy so I may disable it but I'm narrowing down currently which flags are causing the issue.

BuZz

@roslof I sent you an email regarding testing something - No pressure - just if you're comfortable reverting files in RetroPie /using git and familiar with Dreamcast it could help me. Thanks.

roslof

@BuZz no trouble. Would be happy to help. I'm very familiar with Dreamcast, the Pi4B and the three existing emulators.

BuZz

Please update RetroPie-Setup and reinstall lr-flycast from source. The issue was the Makefile using -O3 optimisation and producing unreliable code. Switched to -O2 which is the RetroPie default anyway, and on arm can actually be faster in some cases (although it probably wont make a noticeable difference).

BuZz

Forgot to remove the rollback. Just did that so if you updated already please do it again to get the latest code.

BuZz

Lol. And again. Sorry - I messed up. I removed the git clone line rather than just removing the parameters. Brain fart.

roslof

@BuZz LOL! No worries.

roslof

Confirmed lr-flycast compiles and runs with RetroPie (40ab240).
Will backup and set this as the benchmark build.

hostolis

@BuZz said in After the last update of Retropie for RP4 - Could not successfully build lr-flycast:

@SartreFan that's unrelated (and the missing n is intentional).

Why is it intentional? I was trying yesterday to “killall emulationstation” and I couldn’t, I realized the “n” was missing via “top”

BuZz

@hostolis It's intentional because by default killall will use the first 15 characters of a process.

man killall - you can use the -e option if you want.