lr-mess and lr-mess2016 not compiling

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 ?

mitu

@John_RM_70 What's the actual error ? The 'not found' is just generic because the compilation fails and the file is not found, but the reason for the failure is somewhere in the logs. Try looking for the most recent log file in ~/RetroPie-Setup/logs, it should have the whole compilation commands and where it failed. What version of RetroPie are you using ?

A Former User

@mitu The error is basically the same as the one linked in the OP, the pastebin link.
I can't post my log file because I cleared it all after 2 fails.
I have the latest scripts, and my retropie was updated a couple of days ago, so I am on the most recent version.

mitu

@John_RM_70 We still need to see the logs to determine the error. After the discussion in this topic, the memory has been increased during compilation (swap), so it should have worked. I know I compiled lr-mess, but it took more than a few hours.

A Former User

@mitu It's not "lr-mess" that is the problem, this will compile with a larger swap file (2Gb). It's "lr-mess2016" that won't compile due to the missing file "mess2016_libretro.so". No amount of memory configuration will fix that, it has to be server side, not my side.

mitu

@John_RM_70 Ah, sorry - I forgot about this (and it's even one of my replies that said it). But, there's someone that patched it to work since this topic was last updated - see this topic.

Raleighguy

@mitu Quick question: in which file is the compilation concurrency set?

mitu

@Raleighguy The concurrency is set automatically, based on the #of CPUs you have and the system you're running on. On a PI3, it's probably 2, since it doesn't have enough memory and CPU anyway to sustain 4 compilation threads.