Home Page
Once again, I've revised the build instructions for SDLMAME on Mac OS X.

As always, if you spot any glaring errors/omissions/outright lies, please let me know.

Also, if anyone would be interested in reposting this on their site. please let me know that as well... smile


Building SDLMAME for Mac OS X - A Guide

Welcome to the world of SDLMAME. If you've built SDLMAME for Mac OS X in the past, you'll notice that since version 0.136u1, the build procedures have changed.

If you're new to building (compiling) SDLMAME on Mac OS X, with any luck, you'll find it's not as difficult as you might think.

Either way, Don't Panic! This guide will (hopefully) get you up and running in fairly short order.

Let's get started...

Step 0 - Preliminary Steps - (These need be done only once, with the occasional periodic updates) -

0a) Run Software Update
Your Operating System, and supporting files should be updated prior to compiling SDLMAME (and should be kept up to date regardless) The minimum supported OS for SDLMAME under Mac OS X is 10.7.x (Snow Leopard).

0b) Install/Update Xcode
Xcode is a free developer environment from Apple, and although it will be used to compile SDLMAME, you will not be required to learn how to run it.
It will need to be installed prior to compiling SDLMAME. As of this writing (November 2014) the current version of Xcode is 6.1 (for Mac OS X 10.10 (Yosemite)).
Xcode is free from Apple, in the Mac App Store.

Once you have downloaded Xcode, you'll need to run it. It will download and install a few more pieces at this time. Once it's done, you need to install the command line tools.

On Xcode 6.0 and later, open a Terminal window temporarily and type xcode-select --install and follow the prompts to install the command line tools. (This is a much easier version of this step that I recently found out about).

0c) Install/Update SDL
Simple DirectMedia Layer (SDL) is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and hundreds of Steam games for the Mac and Linux.
Go to http://www.libsdl.org/ , and click the "SDL 2.0" download link in the sidebar, then scroll down to "Mac OS X" under "Runtime Libraries". Download the "SDL-2.0.4.dmg" disk image and open it.
Click 'Macintosh HD' (or whatever your Mac's hard disk is named) in the left pane of a Finder window, then open the Library folder and drag the SDL2.framework folder from the SDL disk image into the 'Frameworks' folder.

Step 0 Recap -
- Run Software Update
- Install/Update Xcode
- Install/Update SDL2


Step 1 - Gather files

1a) Create folder for build files
While not an absolute necessity, keeping various SDLMAME project files in a separate folder will help to avoid confusion while building. For purposes of this exercise, the folder will be called 'MAME Parts'

1b) Get 'Endings' script
Go to http://rbelmont.mameworld.info/?p=527 and download the 'Endings' file (endings.zip). Place this file in the 'MAME Parts' folder.

1c) Get Baseline MAME source
Go to http://mamedev.org/release.html and download the MAME source file (in zip format). Place this file in the 'MAME Parts' folder.

1d) Get update patch files
Go to http://mamedev.org/updates.html and download any of the diff files you do not already have. Place these files in the 'MAME Parts' folder

1e) Unzip, and place files
Go to the 'MAME Parts' folder. Unzip all the files you downloaded. Do not throw away the original zip files, as you may need them again in the future during the development cycle.
Place the endings file, and all patch files into the MAME Source folder.

Step 1 Recap -
- Create folder for build files
- Get 'Endings' script
- Get Baseline MAME source
- Get update patch files
- Unzip, and place files


Step 2 - Prepare for building

2a) Launch Terminal, and set path
Open the Terminal (Applications->Utilities->Terminal). Type 'cd ' (that's cd, and a space), and drag the MAME Source folder to the Terminal window. Hit 'Return'. This sets the path for the subsequent commands.

2b) Run 'Endings'
Type the following line into the Terminal window (or copy and paste, if you prefer) -


Hit return. Wait for the prompt (This may take a while, and it may appear that nothing is happening... Be patient).

2c) Patch files
This is the variable part of the process, as each 'u' update patch needs to be applied in order to the source.

Type the following into the Terminal window -

patch -p0 <xxxxxxxx (that's [patch], [space], -p[zero], [space], <[diff file name])

Where 'xxxxxxxx' equals the name of the diff file you wish to apply. Hit Return, and wait for the prompt.

Repeat for each diff file in order (u1, u2, u3, etc.)

2d) Check the SDLMAME forums for last minute changes
Before proceeding to the next step, check for any last minute changes/fixex/modifications at the SDLMAME forum at http://www.bannister.org/forums/

Step 2 Recap -
- Launch Terminal, and set path
- Run 'Endings'
- Patch files
- Check the SDLMAME forums for last minute changes


Step 3 - Build

3a) Build
Type the following into the Terminal window -



make -j3 (for dual core processors)


make -j5 (for quad core processors)

Hit Return. SDLMAME will auto detect your system type (32 bit or 64 bit), and build accordingly.

3b) Build Tools
As an option, you can build the optional tools that accompany SDLMAME (chdman, and the like) by typing the following into the Terminal window -

make tools

Hit return.

3c) Enjoy!
Congratulations! You've successfully built SDLMAME on Mac OS X!
You may want to rename the Source folder to reflect the version of SDLMAME you just built.
Attach your favorite front end application, and have fun!

Step 3 Recap -
- Build
- Build Tools
- Enjoy!


Future Builds

Provided no modifications were made to the source prior to building, the next patch may simply be applied to the previous build, and the application built again (you can skip step 2b).

If, however, modifications were made to the source prior to building, it is advisable to start with fresh copies of the source, and all the diff files in order (the latest diff file will usually contain fixes for the previous versions).
If you kept the files from steps 1b, c, and,d, just proceed from step 1d.


Troubleshooting FAQ

- I'm told I need to edit a file in Xcode. How do I do this?
Locate the file to be modified, and double click it. Xcode will open the file.
Chances are good that you were told what line of the code to modify. Under the 'Edit' menu, select 'Go to Line...'. Enter the line number, and click the 'Select' button. Make your modification(s), Save the change(s), and quit Xcode.

- I got an error while building. What do I do?
Check the SDLMAME forums at http://www.bannister.org/forums/ to see if this is a known problem, and if there is a fix available. If not, post a question, and someone will try to help you.
You may also want to try starting over at step 1, especially if you were patching an existing build.

- I got an error while patching the source. What do I do?
Start over from step 1, especially if you're patching an existing build. if you continue to have problems, you may be able to get help at the SDLMAME forums at http://www.bannister.org/forums/

- I had to make a modification of some sort prior to building. Will I have to make this modification again in the next version?
No. However, you may need to start over again with the original source, and latest diff files.

- Is there an easier way to do all this?
If you prefer not to build yourself, prebuilt versions of SDLMAME for Mac OS X are available for download at http://sdlmame.parodius.com/

- I've successfully built SDLMAME in Mac OS X... Now what?
That's a whole 'nother document... wink
Thanks. I'll sticky this smile
BTW, r0ni's still making canned Mac Universal binaries, so if you really would rather not compile, go here.
Unfortunately Tiger users are left out there and still have to roll their own..

Just curious RB, do you know why r0ni includes the endings script with his binaries??
I was thinking of making my 136u2 I just compiled the other day for 10.4 available somewhere or other.. Do I need to give folks the endings script too for whatever reason??
Tiger's not supported by SDL 1.2.14 so it's no longer officially supported by SDLMAME either. (We won't actively try to break it of course).

No idea why r0ni includes the "endings" script, probably an oversight.
Did I miss something in the SDL documentation?

As far as I can tell, the minimum System requirement for SDL 1.2.14 is still 10.4.x (Tiger)

Perchance did you mean to say that SDL 1.2.14 is not supported by 10.3.x (Panther)?
Ive been compiling Exult with 1.2.14 since it came out and havent run into any trouble yet. Although its got some bugs of its own that wreak havoc when you play Exult in full screen but other then that no problem..
From what I saw on the SDL list, Tiger is missing an API they needed so it's possible with a sufficiently smart ld.so that not all SDL apps will trigger the fatal death on Tiger.
Guess its time to start looking for a used Intel Mac or G5 hehe.
I had Leopard on it up until last summer but it was just too much of a dog so I went back.
Logic Pro went from being able to play a 20 track song to crawling with 10 tracks so it had to go hehe...

Although with that said, u3 compiled fine yesterday. Crossing my fingers all is still well! Hopefully I can keep up for awhile. MAME OS X was always a fave but I like actually staying current with things hehehe..
I do try to do what I can for PowerPCs - Run and Gun has proper graphics on 'em in u3 (should be fast enough for PS3 peeps like billb too).
Originally Posted By MAMEBase
SDLMAME will auto detect your CPU type (PPC or Intel), and your system type (32 bit or 64 bit), and build accordingly.

actually, on my macbook pro with Snow Leopard, MAME builds 32-bit even if the OS supports 64-bit apps. hence, I had to add PTR64=1. is this expected? or is the identification process at fault (and if this is the case, can I help to fix it?)
Means you're running a 32-bit kernel. OS X is weird in that it can run 64-bit apps on a 32-bit kernel in some cases. The autodetect on Macs only builds 64 bit if you boot the system 64-bit.
according to this article


Snow Leopard is fully capable of running 64bit apps, but the OS uses a 32bit kernel because current hw does not need a 64bit kernel. part of it might as well be true, but I don't currently really care: the important part is the full 64bit capability. hence, I will be able to play n64 at 50% of speed with no frameskip :P

back to the autodetect point, there is no problem if I have to add a PTR64=1, but I would suggest to update the original instructions with a paragraph about Snow Leopard 32bit users because the speed gain with a 64bit compile might be appreciated wink
The real bottom line is that unless you're running a rare handcrafted 3rd party kernel driver for something and/or don't have a Core 2 Duo CPU, you should just reboot with 6-4 held down or whatever the appropriate magic is and then the autodetect will kick in fine.

I will not change the instructions. Always ending up with a safe working executable is my first priority, especially for Mac users.
The autodetect could determine if there is a 64-bit EFI installed:


But it's not a big issue... although that link could be useful for anyone that wants to always boot into a 64-bit kernel.
Originally Posted By Monotremata
Just curious RB, do you know why r0ni includes the endings script with his binaries??

I do? That's definitely a oversight, I have a script I use to build them and package them up, I prob need to do some work on it still, as I haven't changed it since sdlmame merged into baseline. I'll take a look at it.

And I can't support Tiger as I no longer have a PPC Mac. I don't think there is a legit Intel 10.4 disk out there, I could be wrong though.
I'm new to the MAC and still testing out. Are these instructions still valid for XCode 4?

Is there a chance to achieve the same using GCC et al.?

XCode seems awfully big and I would like to keep the clutter down, don't need all the iOS developer stuff and such.
The instructions are still valid, yes.

XCode includes "GCC et al" - it's the easiest way to get it on the Mac. It's equivalent to installing the "development" package group on Linux distros.
Thanks, I'll see how it goes.

I was wondering about the XCode tools since it's 4GB and includes SDK, iOS emulators, etc. But I guess it's the best to go with the standard tools.
You can skip the iOS stuff when you install XCode.
Hey guys long time no see.. Just last week I replaced my ancient dinosaur dual G4 with a dual core G5 to keep my music up and running..

Just getting ready to build a new SDLMAME 142u2 (last one I have was 0.139 and it doesnt work on my G5 after copying over) and have a question about the cpu types..

Now I know it will correctly detect PPC and whatnot, but since my machine is a dual-core and not a regular old dual cpu Mac like before can I (or do I even need to) use the 'make -j3' command or is this an Intel only switch??
-j3 is all purpose - it gets you faster builds on anything with dual cores or dual CPUs or whatever.
Well it built fine and MAME+Gui is working again but now..

I just set all my paths up in M+GUI, and told it to Audit all my roms and its giving me this error:

"While parsing /Volumes/Storage/MAME/ini/mame.ini:
Illegal integer value for numprocessors: "auto"; reverting to auto"

Is this possibly related to the -j3 flag?? I was about to go rebuild it again just using plain old make but figured I would ask first..

Gotta love the G5 compared to my G4.. The initial build of the game list took a couple of minutes if even that. On my old dual 1.6 G4 I would get up and go run errands while waiting for it to finish that first process haha.
it's not related to -j3. try to remove the numprocessors line from mame.ini.
Somehow it just started working right the other day hehe.
Ran my audit, and then found out Im missing like 7gb of ROMs (which is due to PinMAME roms becoming part of the new 'standard' MAME set)..

I ran into some errors compiling 0.142u3 so for now, Im back at just 0.142 until I can get my rom set properly rebuilt.. It hasnt been updated since 0.138 so Ive missed a bunch of changes since last summer..
Would you mind listing what the errors you're having with u3 are? smile
Ill have to rebuild it again, I shouldve wrote it down but just cleaned out my dev folder and went back to 0.142 so I could play catch up with my rom sets.
Ill see if I can get a moment to do it this afternoon.
After a hard drive freeze up a couple weeks ago, I just picked up a spindle of DVD-R's so Im wasting my weekend backing up all 500GB of crap on it (my MAME Roms included) before it dies again hehehe..
Ok just got around to it.. Now that were up to u4 I still went ahead and tried to run u3 just for the sake of doing it..

u3 stops with this error:

typeinfo for driver_device_config<driver_device>in sega.a(segamsys.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [mame] Error 1

After that I did a make clean, and patched u4.
Now u4 is ending with this error:

Compiling src/mame/drivers/suprloco.c...
Compiling src/mame/video/suprloco.c...
cc1plus: warnings being treated as errors
src/mame/video/stvvdp2.c: In function ‘void saturn_vdp2_regs_w(address_space*, offs_t, UINT32, UINT32)’:
src/mame/video/stvvdp2.c:5491: warning: ‘vert_res’ may be used uninitialized in this function
src/mame/video/stvvdp2.c:5491: warning: ‘horz_res’ may be used uninitialized in this function
make: *** [obj/sdl/mame/mame/video/stvvdp2.o] Error 1
make: *** Waiting for unfinished jobs....

Everything up to and including u2 worked just perfect.. So it looks like Im at baseline 0.142 til I can figure it out hehe..
Ok that covered that error..
Got a little farther and hit this:

Compiling src/emu/cpu/i386/i386.c...
cc1plus: warnings being treated as errors
src/emu/cpu/i86/instr286.c: In function ‘void i80286_switch_task(i80286_state*, UINT16, int)’:
src/emu/cpu/i86/instr286.c:215: warning: statement has no effect
src/emu/cpu/i86/instr286.c:216: warning: statement has no effect
src/emu/cpu/i86/instr286.c:225: warning: statement has no effect
src/emu/cpu/i86/instr286.c:274: warning: statement has no effect
src/emu/cpu/i86/instr286.c:275: warning: statement has no effect
src/emu/cpu/i86/instr286.c:281: warning: statement has no effect
src/emu/cpu/i86/instr286.c: In function ‘void i80286_0fpre(i80286_state*)’:
src/emu/cpu/i86/instr286.c:508: warning: statement has no effect
src/emu/cpu/i86/instr286.c:528: warning: statement has no effect
make: *** [obj/sdl/mame/emu/cpu/i86/i286.o] Error 1
make: *** Waiting for unfinished jobs....
I'm a newbie to using Terminal and building, so I have likely made a complete boneheaded mistake. I followed the build instructions for SDLMAME on Mac OS X but I get an error of sdlvideo_init: initialization failed! This happens with the MAME Tunes and MamePGUI front ends.

I had used MAME Tunes with SDLMAME0130-x86 before, but didn't like the faint vector lines on games like Asteroids. I didn't use Terminal to build that one, but I'm wondering if there is some file left over from that usage that is causing the error that I'm having now?

iMac 24" 2.8 GHz Intel Core 2 Duo, 4GB SDRAM, NVIDIA GeForce 8800
What version of OS X? "sdlvideo_init: initialization failed!" is currently a known incompatibility with 10.7 Lion in full-screen mode. You can play in windowed mode while we wait for the SDL guys to cough up a fix.
I'm running Lion, so I guess that's the reason for the problem.

What is windowed mode?

Many thanks for the reply.
Originally Posted By CoramDeo
What is windowed mode?

It's the opposite of full-screen mode, that is it will use a window as its display surface (including window decorations). Start MAME with the option "-window" (or set "window 1" in mame.ini).

The default is "-nowindow" which means full-screen (or "window 0" in mame.ini).
I see. But don't forget that I'm a complete newbie at this. Is there a thread on how to run MAME from Terminal like that?

"Start MAME with the option "-window" (or set "window 1" in mame.ini)" <-- I wouldn't know where to begin with this. I'm used to MacMAME and MAME OS X. I did manage to get MAME_Tunes going with SDLMAME 0130, which I'm presuming was already "built" since I didn't use Terminal, but the vector line games were very dim on the screen.

I appreciate your help and patience. I was 15 when PacMan hit the arcades, and it was glorious smile
Well, that's a bit off-topic now... I suggest you open a new thread (instead of using this sticky one which is meant for build instructions on Mac OS X).

Anyway, the -window option is just a command line argument. You were able to start MAME before (on the command line, I suppose), so just add -window on the command line smile.

If you want to use a front-end instead, well, there are some alternatives... besides MAME_Tunes and others there's QMC2 (the one I wrote) for instance.
I appreciate the advice and heads-up on QM2. I will try to search for newbie threads instead of being off-topic on this one. I wouldn't know where to start to launch MAME from Terminal.
You can do it in MacMAMEinfoX - go to Preferences, then click "Options" button, select the "Video 2" tab, and then choose between "Full Screen" and "Windowed" with the radio buttons.
0.143u8 seems to have a problem (at least) on Mac OS X.

Compiling src/emu/sound/ymz770.c...
cc1plus: warnings being treated as errors
src/emu/sound/ymz770.c: In member function ‘void ymz770_device::internal_reg_write(int, UINT8)’:
src/emu/sound/ymz770.c:931: warning: comparison is always true due to limited range of data type
make: *** [obj/sdl/mame/emu/sound/ymz770.o] Error 1
make: *** Waiting for unfinished jobs....

is this known?, 0.143u7 compiled cleanly.
The thread that was on top of this forum until you posted here contains a workaround for that issue. Please read before writing next time.
Thanks and sorry, I usually do, just didn't realize that specific thread was discussing the same problem I had.
Originally Posted By R. Belmont
What version of OS X? "sdlvideo_init: initialization failed!" is currently a known incompatibility with 10.7 Lion in full-screen mode. You can play in windowed mode while we wait for the SDL guys to cough up a fix.

It seems this hasn't been fixed yet, right?, tried with last full release (0.145)

I upgraded to lion a couple of weeks ago and was still using a mame binary compiled under snow leopard, and with this binary I don't get this error when I execute it in lion. So it doesn't seem to be lion or the source code by themselves, but how it's compiled under lion. Am I right about this?, is it a problem with the newest Xcode?
ok I'm stuck on step 3 when I type "make -j3" it tells me command not found. what am I doing wrong? where should terminal be? mame source folder?
francisohs: Fullscreen on Lion needs the new SDL 1.2.15. Go to http://www.libsdl.org/ and install the new package.

dasaint80: That error indicates you haven't installed Xcode.
On OSX Lion I had to install Xcode and then from inside Xcode install the additional "Command line tools" package (Preferences -> Downloads) to get things working for me.
Ahh, didn't know that was separate now. I'll update the instructions.
svn 27585, clean compile, Mavericks, Xcode 5.02:

Linking mame64...
Undefined symbols for architecture x86_64:
  "typeinfo for centronics_device", referenced from:
      device_finder<centronics_device, false>::findit(bool) in amiga.a(alg.o)
      device_finder<centronics_device, false>::findit(bool) in amiga.a(arcadia.o)
      device_finder<centronics_device, false>::findit(bool) in amiga.a(cd32.o)
      device_finder<centronics_device, false>::findit(bool) in amiga.a(mquake.o)
      device_finder<centronics_device, false>::findit(bool) in amiga.a(upscope.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [mame64] Error 1
Yeah, it's a known thing. It'll get fixed when smf wakes up tomorrow presumably.
I thought I was being clever trying to build with PTR64=0 just now. But it stops in the same place laugh

Maybe you want to see this, I had to use NOWERROR=1 to get past these:
Compiling src/emu/cpu/arm/arm.c...
Compiling src/emu/cpu/arm7/arm7.c...
Compiling src/emu/cpu/arm7/arm7thmb.c...
src/osd/sdl/debugosx.m:832:69: error: values of type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long'
      instead [-Werror,-Wformat]
                        NSString        *title = [NSString stringWithFormat:@"%ld-byte Chunks", tag];
                                                                              ~~~               ^~~
src/osd/sdl/debugosx.m:835:63: error: values of type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long'
      instead [-Werror,-Wformat]
  ...keyEquivalent:[NSString stringWithFormat:@"%ld", tag]
                                                ~~~   ^~~
2 errors generated.
make: *** [obj/sdl/osd/sdl/debugosx.o] Error 1

I guess they haven't been caught because nobody builds 32-bit SDLMAME anymore.
OS X Intel is very much a 64-bit only club now, especially with 10.9 being a free upgrade to anyone all the way back.

Let me be very clear before anyone else hurts something trying to be clever: current SVN does not build on Windows official tools. It does not build on Linux GCC. It does not build on Windows MSVC. It does not build on Clang on either Linux or OS X. It does not build on GCC on OS X. You cannot build it in your house. You cannot build it by clicking your mouse. It's not just you, it's really broken.
I have found that following the instructions strictly, and placing everything in directory named MAME Parts, gives ample space for error, as GENIE will be led into monstrous errors of slash fiction(al directories). But I have come to a conclusion from which there is no escape: the fault lies not in our third-party libraries, but in our scripts. (All puns intentional.)
And we accept pull requests any time at http://github.org/mamedev/mame/
I spoke too soon about the problem not being with GENIE. SDLMAME might have to discontinue automatic inclusion of src/osd/sdl/sdlprefix.h for the moment because of a stupid GENIE bug which applies the wrong type of escaping (HTML rather than shell) to FORCE_INCLUDE paths.

Should I just leave the first few lines of code in scripts/src/osd/sdl_cfg.lua commented out? (The defines seem to be doing the same thing as sdlprefix.h, at least for OS X.) Should I try to re-include sdlprefix.h by some currently less broken way? Should I make modifications in 3rdparty/genie/src, or is that sort of thing not supposed to be done? (I have already submitted them to the GENIE project as a pull request.)
We have a great relationship with Branimir, and he generally accepts patches to bgfx and GENie from Micko and me. How about submitting a patch to fix the problem in GENie if you're sure that's where it is?
I'm... not understanding what the problem is. I can build beautifully on OS X, including sdlprefix.h, and I believe Vas can too. Are you trying to build on 10.4 or something?

ETA: Oh, I get it. You're building from a directory with a space in it. That doesn't even work on Windows. Stop doing it.

Oh, I get it. You're building from a directory with a space in it. That doesn't even work on Windows. Stop doing it.

"Doctor, it hurts when I do this." "Well, don't do that, then!" I may be no medical expert, but in this case I know I can do better than that. Anyway, it works now that I've fixed it, and I've submitted the pull request. Since the GENie license does allow modifications, I decided to apply the same patch I submitted to the GENie project, which means that sdl_cfg.lua can stay exactly as it was.
Yeah, that's exactly the joke I was headed for smile Glad to hear you were able to resolve the issue at the right level.
...and you broke the all-important SOURCES= tiny build option. Ouch!

Test case: "make clean; make SOURCES=src/mame/drivers/namcos23.cpp REGENIE=1 -j3". The wrong parameters are passed to makedep.py.

I've reverted your changes in MAME to unblock people working on stuff; please resubmit when you've fixed the problem.
I figured out what was breaking makedep.py in the SOURCES build (which is, of course, handled completely differently from the tiny subtarget). The calls to _MAKE.esc are still in order, but some arguments just need to keep their .. " " .. from each other.
Great! In the future, please put functionally unrelated changes in separate requests though; now we can't put the Genie fixes back until we find out if you've violated Olivier's architectural direction for the memory system.
Olivier's architectural direction for the memory system

Are you referring to the total revamp that, so far as I know, has only been publicized in the form of a vague outline? (At least that to-do is only two months old now; I hope it won't be still there as is in two years.)
As I understand it, there's a stronger-form version in his head, based on (among other things) the Emulators.com white papers about TLBs and stuff. If you have specific ideas, it's possible to reply to that outline (as others have about other outlines).
I think the minimum OS version needs to be updated because mame now requires gcc 5, and that doesn't come with the last Xcode version that can be installed in 10.7. Will not install in brew, either. I think 10.9 is the bare minimum to build mame now.
Said it before, I'll say it again: I build MAME on 10.6.8 "Snow Leopard" any time I want using Clang 3.7 and libc++ from MacPorts. If you're building with GCC on OSX, you're pretty much unsupported at this point.
Originally Posted By Vas Crabb
Said it before, I'll say it again: I build MAME on 10.6.8 "Snow Leopard" any time I want using Clang 3.7 and libc++ from MacPorts. If you're building with GCC on OSX, you're pretty much unsupported at this point.

Then instructions to install and build with the necessary clang version should be stickied instead of this, or in addition.
This thread is not the official documentation. Please refer to the documentation site:

Note that it lists 10.9 as a prerequisite for the "happy path", and also lists MacPorts prerequisites for 10.6. You can submit proposed changes via pull requests.
I'm aware I'm "bumping" a necro thread here, but this is relevant to the topic at hand. As of 227 mame is failing to build on 10.9.

I'm literally at a loss as to what/why it refuses to build. I've tried macports builds of gcc 10.2, gcc 8, clang3.7, clang6.0, clang11.0

I even went to the compiling MAME page and setup my environment exactly like it specifies and used the presented arguments to see if it would get anywhere, and nothing. The most I've got is the tools built, but the mame binary will not build. I've seen errors with bgfx and dear-imgui pop up with different things, builds oob on 10.15 but I've got nothing on 10.9.

Using this command: make -j5 PTR64=1 NOWERROR=1 TOOLS=1 TARGETOS=macosx OVERRIDE_CC=/opt/local/bin/clang-mp-3.7 OVERRIDE_CXX=/opt/local/bin/clang++-mp-3.7 PYTHON_EXECUTABLE=/opt/local/bin/python2.7 ARCHOPTS=-stdlib=libc++

This is what I get for my failure:
make -j5 PTR64=1 NOWERROR=1 TOOLS=1 TARGETOS=macosx OVERRIDE_CC=/opt/local/bin/clang-mp-3.7 OVERRIDE_CXX=/opt/local/bin/clang++-mp-3.7 PYTHON_EXECUTABLE=/opt/local/bin/python2.7 ARCHOPTS=-stdlib=libc++
Clang 6.0 detected
/Applications/Xcode.app/Contents/Developer/usr/bin/make -R --no-print-directory -C build/projects/sdl/mame/gmake-osx-clang config=release64 precompile
Precompiling src/emu/emu.h...
error: invalid value 'c++17' in '-std=c++17'
make[2]: *** [../../../../osx_clang/obj/x64/Release/emu.h.gch] Error 1
make[1]: *** [precompile] Error 2
make: *** [macosx_x64_clang] Error 2

Any ideas guys? This is making me want to pull my hair out!
0.227 uses the C++17 language standard, which came out in 2017. Because MacPorts and Homebrew's compilers rely on the libstdc++ that ships with the OS rather than using the matching version from GCC or LLVM/Clang, that means that 10.14 is now basically the floor for building MAME on macOS.
Originally Posted by R. Belmont
0.227 uses the C++17 language standard, which came out in 2017. Because MacPorts and Homebrew's compilers rely on the libstdc++ that ships with the OS rather than using the matching version from GCC or LLVM/Clang, that means that 10.14 is now basically the floor for building MAME on macOS.

Well that explains that. Guess I might as well just build and ship with 10.15 for now. That's where I'm stuck on my mbp, and about all I can do until I get an M1.

Thanks for helping with my ignorance RB wink
Not a problem. We tried to come up with a solution for older macOS versions but Homebrew and MacPorts didn't want to throw things out of sync with the OS even though it's fairly common on Windows and Linux.

Incidentally, the compile speeds on the M1 are great. I have a Mac mini M1 with 16 GB of RAM and it compiles in the vicinity of twice as fast as my 2020 MacBook Pro with the fastest build-to-order Core i7.
I am excited to get into an M1 machine eventually. It’s been quite a while since I’ve had a upgrade to an Apple machine, so I am very eager for all the speed ups, it will be really nice to have. I was thinking of going the same route with a Mini and 16gb ram, can’t wait to see it in action!
Folks, after a lot of hard work over the past two months, I'm pleased to announce that MacPorts now provides up-to-date binary builds of Mame! Those are available across a very wide range of macOS versions, from 10.6 through Big Sur. We even provide an M1-native binary for the latter.

The latest Mame release - 0.227 - is supported for macOS 10.14+. While earlier macOS versions are just one release behind, at 0.226.

We provide a full build for the core Mame application, and also include the command-line tools.

If you're interested in taking it for a spin, it's easy: Install MacPorts if necessary, and then run the following from Terminal:
sudo port install mame

Once the installation is completed, some brief usage notes will be displayed:
mame has the following notes:
  Mame is launched via command 'mame'.
  If a blank screen is encountered, press ESC to exit, and then re-launch with an
  alternative video option.
      mame -video accel
      mame -video opengl
  If you're new to Mame, our tutorial will quickly walk you through the process of
  setting up a new game:
  Mame tools are installed. Each has a prefix of 'mame-', to avoid conflicts with
  system tools.

The 'mame' command is backed by a simple launcher script, which sets a few critical paths for proper operation. (Including languages, plugins, bgfx, and several others.) Those can be overridden by specifying them yourself, if desired.

Otherwise, Mame operates just as you'd expect.

Give it a try, and please feel free to provide feedback... positive or negative.

Cheers and Thanks,
-Chris Nielsen
MacPorts Mame Maintainer
Thanks Chris, that's great!
Let me know if there are any other forums, etc, where such an announcement might make sense. (And folks are certainly welcome to forward the info as well.)
You might want to announce it on reddit at r/mame and r/emulation
Originally Posted by Chris Nielsen
The latest Mame release - 0.227 - is supported for macOS 10.14+. While earlier macOS versions are just one release behind, at 0.226.

Is there a particular reason why 10.13 and below is on 0.226? and only 10.14 and above has 0.227?

I'm curious will the older systems have an up to date port in due time?

I'm overly just curious why it isn't synced across the board and of the workflow.
0.227 cannot build or run on pre-10.14 systems without significant intervention. 10.14 is the first version of macOS to include a C++17 compliant libstdc++, and 0.227 requires C++17, which is why the required GCC version on Linux also took a leap forward.

Currently the requirement is more of a flex than a benefit, but that will likely change.
Folks, Mame 0.230 is now available via MacPorts. As a reminder, the latest release requires MacOS 10.14+. For earlier MacOS releases, 0.226 will be installed.

If you already have an older version of Mame installed via MacPorts, you can upgrade it via the following command:

$ sudo port upgrade mame

For first-time users, please refer to this post for an overview of installation/use:


As always, comments/feedback is welcome.

Cheers and Thanks,
-Chris Nielsen
MacPorts Mame Maintainer
Thank you for posting this.

I have a question/problem (A Black (blank) Screen). Note: I am working under the premise that entering ./mame64 from the applicable directory should be enough to see MAME's menu.

Note for admin - as this issue is resolved mostly, it may help others but if this issue is already covered and my post is out of place, feel free to delete it. Thanks for understanding.

If this is not the ideal thread to post this please let me know and I will repost in whichever forum room you recommend.

Mac OS High Sierra 10.13.6
mame0226-64bit (downloaded from https://sdlmame.lngn.net/stable/mame0226-64bit.zip)
SDL 2.0 (Installed in /Library/Frameworks)
MacPorts not in use as I am afraid it may conflict with brew

Mac Restarted after SDL install
From the command line (terminal), navigated to the folder containing the mame64
uploaded one ROM to the roms folder
tried ./mame64 (a blank screen appears)
tried ./mame64 -createconfig (created a mame.ini file)
tried ./mame64 -video accel (a blank screen appears)
tried ./mame64 -video opengl (a blank screen appears)
tried ./mame64 [with no files in roms folder (a blank screen appears)

For some reason my ESC appears defective - just discovered so when I get the blank screen I use command-H to hide the mame64 executable followed by a force quit of the executable from the dock.

I have some very old notes that I wrote some time ago to help me with version mame0205-64bit so I installed it because my old notes suggest it did work. I launched mame64 (version 0205-64bit) but there is only one change from what happens with mame0226-64bit, I see a 1 pixel wide white frame that wraps around the screen and displays for about 1 second and then the screen goes black.

I also tried, as a test, NOTE: I am not concerned about a ROM not executing.
./mame64 /Volumes/4TB\ Internal/ORGANIZED/Emulation/mame0226-64bit/roms\ old/arabian.7z
ic1rev2.87 NOT FOUND (tried in arabian)
ic2rev2.88 NOT FOUND (tried in arabian)
ic3rev2.89 NOT FOUND (tried in arabian)
ic4rev2.90 NOT FOUND (tried in arabian)
tvg-91.ic84 NOT FOUND (tried in arabian)
tvg-92.ic85 NOT FOUND (tried in arabian)
tvg-93.ic86 NOT FOUND (tried in arabian)
tvg-94.ic87 NOT FOUND (tried in arabian)
sun-8212.ic3 NOT FOUND (tried in arabian)
Fatal error: Required files are missing, the machine cannot be run.

So MAME appears to be working to some extent.

Some progress

I tried ./mame64 -debug -log > log.txt
For some reason, two terminal windows appear, one is all blank (black) and the second one has the mame menu. I am surprised that the -debug flag doesn't go full screen which helped me locate the problem as two windows show up, not full screen. Interestingly, the -debug flag also results in two exec icons visible from the dock.

I guess this is resolved to some extent. I will continue to explore.
© Forums