Installation of Mamedev MAME

mitu

@George said in Installation of Mamedev MAME:

. Am I correct in my understanding that I should be able to cross-compile MAME for ARM/Raspbian Stretch on an Intel/Ubuntu machine?

Yes, that should work. While not specifically for MAME, I did cross-compile lr-mame and lr-mess, but not using the RetroPie provided scripts - though it certainly should be possible.
What Ubuntu version and architecture are you using for cross-compilation ?

barbudreadmon

@George it might be a good idea to only include playable drivers when building mame for pi, i don't see the point of having all those 3d/preliminary drivers that will never run at playable speed on a rpi, except if you really want to compile for 2 days and a half, and exhaust your ram and disk space with huge executables.

For the remainder, it is described at https://docs.mamedev.org/initialsetup/compilingmame.html

You can do driver specific builds by using SOURCES=<driver> in your make statement. For instance, building Pac-Man by itself would be make SOURCES=src/mame/drivers/pacman.cpp REGENIE=1 including the necessary REGENIE for rebuilding the settings.

Ofc, it would mean managing a list of those drivers

markwkidd

@barbudreadmon said in Installation of Mamedev MAME:

Ofc, it would mean managing a list of those drivers

The driver list could be generated by script but yeah of course someone's then got to write the script :|

mitu

@George I did try to cross-compile from an Ubuntu 18.0.4 host and it seems to work, but there's one gotcha - you need to copy your scriptmodule to the chroot that gets created. So the steps would be

# build the cross-compiler 
sudo ./retropie_packages.sh crosscomp setup stretch

# Compile one small package in the chroot, to get it created 
sudo   ./retropie_packages.sh builder chroot_build module lr-picodrive

# Copy your scriptmodule to $HOME/RetroPie-Setup/tmp/build/builder/stretch/home/pi/RetroPie-Setup/...., then run the cross-compilation.
sudo   ./retropie_packages.sh builder chroot_build module mame

Note that the builder will cross compile twice - for RPI 0/1 and for RPI 2/3. I haven't figured out how to compile for one platform only, but you can modify the builder script to exclude the platforms you're not interested in.
Some steps in the MAME compilation will be executed completely on the ARM chroot (.lay files 'compilation'), they won't get any significant speed up from cross-compilation, but overall it should be considerably faster to get a PI build using cross-compilation.

Leaving aside the cross-compilation, I have just one suggestion for your scriptmodule - you're currently hardcoding the MAME tag release, but you can get the latest release tag dynamically from Github. Look at how this is implemented in the Skyscraper module, here and here.

George

Thanks for the info @mitu. I've been trying to get a handle on why this is not compiling. I'm still getting stuck at that first step:

sudo ./retropie_packages.sh crosscomp setup stretch

This fails while building libgcc

Makefile:883: recipe for target '_gcov_dump.o' failed
Makefile:883: recipe for target '_gcov_flush.o' failed
Makefile:883: recipe for target '_gcov_fork.o' failed

Here's some info on my platform:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic

The processor is an AMD processor and not Intel though. Not sure if that would actually make any difference here though. There don't seem to be any errors that would indicate a missing dependency either.

@barbudreadmon and @markwkidd, yeah the script could be modified to only include specific drivers. That would need some experimentation to see how much it would reduce the compile time. Thanks for the info.

- George

mitu

@George said in Installation of Mamedev MAME:

The processor is an AMD processor and not Intel though. Not sure if that would actually make any difference here though. There don't seem to be any errors that would indicate a missing dependency either.

The CPU doesn't make a difference, I actually run this also on an AMD, with the same release of Bionic. Must be something else I've run before that made the setup work.

George

This is pretty hard to track down, but I think I've made some progress. I ran apt update/upgrade a couple of times just to be sure I had everything up to date. Perhaps something had not gotten upgraded in my previous attempts. Now, it looks like everything is compiling, but the last step is still failing:

= = = = = = = = = = = = = = = = = = = = =
Running action 'switch_distcc' for 'crosscomp' : Create am arm cross compiler env - based on examples from http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler
= = = = = = = = = = = = = = = = = = = = =

'/opt/retropie/admin/crosscomp/bin/cc' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-gcc'
'/opt/retropie/admin/crosscomp/bin/gcc' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-gcc'
'/opt/retropie/admin/crosscomp/bin/arm-linux-gnueabihf-gcc' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-gcc'
'/opt/retropie/admin/crosscomp/bin/c++' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-g++'
'/opt/retropie/admin/crosscomp/bin/g++' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-g++'
'/opt/retropie/admin/crosscomp/bin/arm-linux-gnueabihf-g++' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-g++'
sed: can't read /etc/init.d/distcc: No such file or directory
Failed to restart distcc.service: Unit distcc.service not found.

I'll dig in some more and see if I can resolve it.

- George

mitu

@George Install distcc manually on the host.

George

Ah, on a whim, I ran apt install distcc and it looks like that might be the missing piece. Taking a look at the original post I find evidence that this might be the case.

https://retropie.org.uk/forum/post/166552

EDIT: Thanks @mitu, guess we cross-posted.

@George Install distcc manually on the host.

- George

George

I believe I've gotten past the first step. Now, I'm trying to do the following:

sudo   ./retropie_packages.sh builder chroot_build module lr-picodrive

But it gets caught at:

= = = = = = = = = = = = = = = = = = = = =
Running action 'chroot' for 'image' : Create/Manage RetroPie images
= = = = = = = = = = = = = = = = = = = = =

Chrooting to /home/myuser/Downloads/RetroPie-Setup/tmp/build/builder/stretch ...
Unknown host QEMU_IFLA type: 43
Unknown host QEMU_IFLA type: 43
sudo: /home/pi/RetroPie-Setup/retropie_packages.sh: command not found

I note that my RetroPie-Setup directory is not in the user's home directory, but under a secondary Downloads directory. But /home/myuser/Downloads/RetroPie-Setup/tmp/build/builder/stretch/home/pi/ is created at least.

- George

mitu

@George said in Installation of Mamedev MAME:

I note that my RetroPie-Setup directory is not in the user's home directory, but under a secondary Downloads directory

I installed RetroPie-Setup on the host (i.e. like a PC installation - see the docs) - maybe that makes a difference.

George

Gotcha. When the script was downloading stretch, I mistakenly thought that was the RetroPie build.

So I'm starting out with:

cd /home/myuser/Downloads/RetroPie-Setup/tmp/build/builder/stretch/home/pi/
git clone --depth=1 https://github.com/RetroPie/RetroPie-Setup.git

I'm wondering if I need to run the Basic Install process and if that needs to be in the chroot'ed environment as well. Going to try without first.

Thanks for all your help @mitu.

- George

George

Looks like it's doing more than it did last time, but I see a lot of the following warnings:

distcc[4372] (dcc_build_somewhere) Warning: failed to distribute, running locally instead

Is this something to be concerned about?

- George

mitu

@George said in Installation of Mamedev MAME:

Is this something to be concerned about?

:( it means it's compiling in the chroot, instead of sending the compilation to the host (via distcc). Might be as slow as on a Pi (but without the swapping).

George

Ok, good to know. I'm not too concerned about compile time, since this will have more RAM, and won't overheat and get throttled.

I got this error at the end of building lr-picodrive:

= = = = = = = = = = = = = = = = = = = = =
Removing 'lr-picodrive' : Sega 8/16 bit emu - picodrive arm optimised libretro core
= = = = = = = = = = = = = = = = = = = = =

/opt/retropie/libretrocores/lr-picodrive /
/home/pi/RetroPie/roms /opt/retropie/libretrocores/lr-picodrive /
/opt/retropie/libretrocores/lr-picodrive /
Removed directory /opt/retropie/libretrocores/lr-picodrive
/
sending incremental file list
rsync: mkdir "/home/myuser/RetroPie-Setup/tmp/archives" failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(675) [Receiver=3.1.2]

But I remember that I have my RetroPie-Setup in ~/Downloads/. I resolved it by running:

mkdir -p /home/myuser/RetroPie-Setup/tmp/archives

I'm now running a crosscomp test with my mame.sh scriptmodule. I removed the !armv6 so it should build for rpi1/2. Fingers crossed!

- George

George

Looks like MAME is compiling. I modified /etc/default/distcc so that STARTDISTCC was set to true, but I still get "failed to distribute" warnings. It seems mostly to happen on .c files and not .cpp files though, which is odd.

I started the compile last night and it is still running. I hope it doesn't take a month. ;-)

I looked into cross-compiling MAME using other methods. Definitely a complex task and not very well documented. The MAME documentation has something about cross-compiling as well as a GitHub ticket, but nothing with enough detail (basically already done for me). The search continues.

- George

mitu

@George said in Installation of Mamedev MAME:

Looks like MAME is compiling. I modified /etc/default/distcc so that STARTDISTCC was set to true, but I still get "failed to distribute" warnings. It seems mostly to happen on .c files and not .cpp files though, which is odd.

Sometimes distcc (the client) would refuse to distribute the compilation, depending on the compiler options, so this might not be related to the service status, but locally on what the compiler requests. I remember I tried this when trying to cross-compile (using the same method, via distcc) lr-mess, distcc would refuse to distribute compiler lines that included -x cpp or -x c - this was later fixed in distcc (https://github.com/distcc/distcc/commit/09656168b2a981484fba1814b02de0f12ecf2407), but the version from 18.04 might not include that improvement.

George

Awesome. The cross-compiling is complete for both rpi1 and rpi2 builds. I now have two files:

stretch/rpi1/emulators/mame.tar.gz
stretch/rpi2/emulators/mame.tar.gz

I guess I have to copy the tgz files over to each respective Pi, but I think I'll need to look up how to install as binary as I didn't add that as an option in the script. I'll see if I can find some info out on the original cross-compiling post, but any pointers would be very helpful!

Thanks again for all the help!

- George

mitu

@George said in Installation of Mamedev MAME:

I guess I have to copy the tgz files over to each respective Pi, but I think I'll need to look up how to install as binary as I didn't add that as an option in the script.

You don't have to - just need to make sure your install step returns all the files needed to be installed in md_ret_files. The cross compile would take those files and create the archive and upload them to the RetroPie server (via rsync), then the setup script would detect if there's binary upload (archive) on the RetroPie's server and offer the option to install from binary.

After the binary archive is downloaded, it's unpacked in the install folder (/opt/retropie/emulators/mamedev) and then the configure step is executed - without any build steps.

I'll see if I can find some info out on the original cross-compiling post, but any pointers would be very helpful!

George

Gotcha. So there's no way for me to test the download from RetroPie servers (unless someone puts binaries there). But I can test md_ret_files and the configure step.

Quick question. I've currently set the script to run on v0207. Looks like they just released v0208. Yay. Any thoughts on just running on master vs. a specific release tag?