lr-mess and lr-mess2016 not compiling

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.