lr-mess and lr-mess2016 not compiling

DougA

Raspberry pi 3b
32GB Sandisk SD card
64GB Sandisk usb drive
Retropie 4.4.1 image from here
Dragonrise zerodelay controller
Canakit 5v 2.5A power supply
Logitech K400 wireless keyboard/trackpad

Is anyone else having issues compiling either lr-mess or lr-mess2016 from the experimental packages list? I tried both last night and in both cases I got a message
Could not successfully build lr-mess2016 - MESS emulator - MESS Port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mess2016/mess2016_libretro.so not found)
or the equivalent for lr-mess

Checking the log file for the compile, everything seemed to be compiling fine for lr-mess2106 until it got to
Compiling 3rdparty/bgfx/src/bgfx.cpp...
when I got pages of errors and then it gave up after about 25 minutes of total; compile time.

lr-mess got much further (3 1/2 hrs) but threw up over an internal compiler error
Compiling src/lib/formats/tzx_cas.cpp...
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.

DougA

@mitu By total coincidence, I posted almost the same issue just now, before seeing this thread. I also got the same errors when I tried to compile those two emulators last night. In my case I am attempting to emulate a BBC Micro. I hadn't quit emulationstation either, though I was working directly on the Pi

mitu

@douga @jsevakis I'm not sure if quitting ES would be enough, I remember a topic about a month ago about lr-mess compilation that - besides taking ages - doesn't succeed. You can try to quit ES, then run the compilation directly to see if it completes, but I'd leave it over night.
EDIT: I've merged your other topic to this one.

DougA

@mitu well, it fell over at 3 1/2 hours running from inside Emulationstation, and it has run longer outside of it. I guess I will find out tomorrow morning.

jsevakis

@mitu Yeah, I just tried it without EmulationStation running and got the same error. There's probably not much else I can do to free up memory, is there?

In which case, this build script is simply not RPi compatible without some sort of fix for this RAM requirement. ☹️

DougA

@jsevakis Me to. Exactly the same issue

DougA

@mitu @jsevakis I am going to try compiling it on a PC running RetroPie on top of Ubuntu over the weekend, just to see if I can reproduce the error there too

clewis

If anyone gets this figured out I would love to hear a solution. Cross compiling would probably be over my head.

BuZz

Building in emulated chroot for example which is how I prepare binaries (with distcc cross compiler). I'll test increasing swap more - it was enough on Jessie. I'll have a look on Stretch.

clewis

@buzz

Thanks! Hope it works out!

I can follow directions and looking to get lr-mame2016 running.

MadHorse

I have the same problem with lr-mame2016, did anyone find a solution for this error?
Thank you

hermit

I have a similar problem with lr-mess: after about 12 hours it was "stuck" on the compilation of http.cpp

raspberry 3b
retropie 4.4 Stretch

Darksavior

@hermit It's still compiling. Press a key or button to see that you still get a response. To this day I can't get lr-mame and lr-mess to compile. I'm not trying again when lr-mess used to take over a day to compile on my pi3b only to fail. I have messed around with temp folders so ill remove that before trying again.

I wish someone would provide a linux distro with cross compiling all set up. or a nice guide.

hermit

ok thanks

mitu

I took a stab at compiling lr-mess (not lr-mame2016), both on the Pi and on a setup as the one described by @buzz (cross-compiling with distcc).

Natively, on the Pi, the compilation crashed with not enough memory. I made the following modifications:

reduced the compilation concurrency so only 1 file is compiled at a time (-j1)
increased the swap added during compilation so you get a total of 2Gb or RAM (now the script ensures you have 1.4 Gb by adding a swap file).
reduced the number of drivers included in the core - only bbcb, arcadia and crvision were included.

The compilation took more than 10h, but it finished and produced the mess_libretro.so core file (which is 45 Mb un-stripped, 27 Mb stripped).

Cross-compiling from an Raspbian chroot via distcc is ... still compiling. Here, I reduced the make concurrency to 2 parallel compilations (-j2), but didn't exclude any of the drivers (so it should produce a full lr-mess core). The problem here is that distcc does not work 100% for cross-compiling because:

the build system in MAME adds the -x c++ argument to almost any driver compilation
distcc refuses to cross-compile this. As a consequence, there's no cross-compilation for any emulator included, so that's why I'm still waiting.
It seems that distcc has a fix for refusing the compilation with -x c++, but the latest version available right now (in Debian) doesn't seem to include it. I might compile from source and re-try to see if there's any progress.

I intend to re-run the native compilation on the Pi, maybe trying with -j2 to run 2 parallel compilations, and to include the full range of drivers in the core. Even adding a bigger swap file ( totaling 2G + or RAM), I still think the compilation might exceed 24h and be very slow on the Pi.
Still waiting for the cross-compile to finish and re-try with a newer distcc.

As a side note for cross-compilation, MAME seems to have support for it with a special target for Raspberry PI. The problem is that setting up a proper Raspbian ARM image to be used for cross-compilation is not trivial, although I think it can be automated.

EDIT: cross-compilation finished, took almost 12h. Note that I haven't tested any of the resulting cores to see if it actually runs.

circuitcreature

I know this is an older post, but you do need to increase the swap space. I make a 4GB temporarily to get the compile to finish.
Edit: It also takes forever in the PI, im about 24 hours in.

mitu

OK, so I re-tried the compilation for both native and cross-compilation configuration

Native - compiled with 2Gb or RAM (total) and 2 compiling processes (-j2). It finished in about 31 hours (stock 3B, no overclock, just heatsink).

[...]
Building driver list...
837 source file(s) found
3043 driver(s) found
Compiling generated/version.cpp...
Compiling generated/mame/mess/drivlist.cpp...
Linking mess_libretro.so...
Removing additional swap

real    1911m50.530s
user    777m4.522s
sys     79m13.794s

As expected, the compilation is memory bound, with a few outliers that need > 1 Gb to compile and will effectively stop the compilation with heavy swapping - CPU is < 5% while the system just does swapping. For most of the compilation -j4 would be fine, but for these memory intensive files it will just increase the compilation times since the system will just try to accommodate 4 compilation processes.

Cross-compiling - I updated distcc to get around the limitations noticed in my previous post, but it still refuses to compile most of the .cpp files (while compiling fine any .c sources). It might be a bug in distcc, but I'll need to check with a simpler setup if it's reproducible.

All-in-all, I think for a RPI using -j2 and at least 2GB or RAM (right now it's set at 1400 Mb in the lr-mess.sh scriptmodule) would make the compilation finish.

hermit

I managed to compile lr-mess in more than 30 hours
I'm worried about the update :(
it would take a procedure where you can choose the drivers / cores

mitu

@hermit said in lr-mess and lr-mess2016 not compiling:

it would take a procedure where you can choose the drivers / cores

Just move - before the update - the emulator folder and it shouldn't be caught by the update.

A Former User

Sorry for the bump, it seems like the more appropriate topic since it's essentially the same question.

Has anyone managed to successfully compile lr-mess2016 ?

I just get the same bug "mess2016_libretro.so not found", after a few hours.
This seems like the holy grail for mess emulation on the Pi, since lr-mess2016 would be a massive jump in quality from the old mess we currently have. Many machines have had a few years-worth of fixes, including those with which we still struggle to get working properly...i.e.. BBC...etc...
Would love to get this on the Pi, and I think many here would also feel the same way. Is there any chance of a fix for the compile error ?