Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
lr-mgba segfaults
#1
With default 3.0 installation lr-mgba segfaults on any GBA rom on my OPi PC, while lr-gpsp and lr-vba-next works OK. Tried updating it from source but that did not help, every rom crashes even before displaying GBA bios logo.

Did anyone else noticed this?
Reply
#2
Yes, we've seen it and switching to GPSP was the solution. We'll put on todo list.
Reply
#3
Thanks, will wait for proper resolution.

On 2.5 mgba had the best performance, and found only 1 game that did not work well (Big Mutha Truckers). Now tried Baldur's Gate: DA with both gpsp and vba-next and found them choppy (gpsp - audio + video, vba-next - video).
Reply
#4
OK, recompiled and tested from SSH, seems to be working with uncompressed .gba roms
http://www.retrorangepi.org/temp/mgba_libretro.so
Reply
#5
(12-29-2016, 06:21 PM)alexkidd Wrote: OK, recompiled and tested from SSH, seems to be working with uncompressed .gba roms
http://www.retrorangepi.org/temp/mgba_libretro.so

Tested, it works Smile Thank you!
Reply
#6
How does the build differ from the binary we get by doing "update from source" in setup script? Any patches?
Reply
#7
I tried from libretro github, i think the update script use retropie fork
Reply
#8
AFAIK no, from what I see from build log:

git clone --depth 1 "https://github.com/libretro/mgba.git" "/home/pi/RetroPie-Setup/tmp/build/lr-mgba"

I confirm that your build works OK, the one I'm doing from setup script is not.
Reply
#9
strange, i thought it was retropie's... I just ran:

git clone https://github.com/libretro/mgba
make -j2 -f Makefile.libretro

i wonder if the --depth 1 makes any difference
Reply
#10
Cloned repo with --depth 1 and got working binary in the end.

Here's what script does:

Code:
function build_lr-mgba() {
   make -f Makefile.libretro clean
   if isPlatform "neon"; then
       make -f Makefile.libretro HAVE_NEON=1
   else
       make -f Makefile.libretro
   fi
   md_ret_require="$md_build/mgba_libretro.so"
}

This does not differ from what I'm doing manually (HAVE_NEON is not used anyway).

Okay, found something. Script adds extra CFLAGS (at the beginning):

Code:
-O2 -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -pipe

-O2 is later overwritten but others are not. All except -pipe are added in scriptmodules/system.sh:


Code:
function platform_armv7-mali() {
    __default_cflags="-O2 -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations"
    __default_asflags=""
    __default_makeflags="-j2"
    __platform_flags="arm armv7 neon mali"
    __has_binaries=0
}

Build produces working binary if I remove all CFLAGS changes (left __default_cflags=""). Will try to find these that break things but not today, now I'm going to celebrate New Year's Eve. Big Grin

It's -mfpu=neon-vfpv4 that breaks things on OPi PC. To fix "Update from source" feature in RetroPie-Setup remove this value from /home/pi/RetroPie-Setup/scriptmodules/system.sh line 261 so it reads:


Code:
__default_cflags="-O2 -march=armv7-a -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations"


After that change build produces working binary lr-mgba core.

Happy New Year!
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  dosbox segfaults in 3.0.1 greenais 2 44 10-18-2017, 10:39 PM
Last Post: greenais

Forum Jump:


Users browsing this thread: 1 Guest(s)