# Compiling MAME

## All Platforms

- To compile MAME, you need a C++20 compiler and runtime library. We support building with GCC version 11 or later and clang version 13 or later. MAME should run with GNU libstdc++ version 11 or later or libc++ version 11 or later. The initial release of any major version of GCC should be avoided. For example, if you want to compile MAME with GCC 12, you should use version 12.1 or later.

- Whenever you are changing build parameters, (for example changing optimisation settings, or adding tools to the compile list), or system drivers sources are added, removed, or renamed, the project files need to be regenerated. You can do this by adding REGENIE=1 to the make arguments, or updating the modification time of the makefile (for example using the touch command). Failure to do this may cause difficult to troubleshoot problems.

- If you want to add various additional tools to the compile, such as chdman, add a TOOLS=1 to your make command, like make REGENIE=1 TOOLS=1

- You can build an emulator for a subset of the systems supported by MAME by using SOURCES=<driver>,... in your make command. For example make SUBTARGET=pacem SOURCES=src/mame/pacman/pacman.cpp REGENIE=1 would build an emulator called pacem including the system drivers from the source file pacman.cpp (REGENIE=1 is specified to ensure project files are regenerated). You can specify folders to include their entire contents, and you can separate multiple files/folders with commas. You can also omit the src/mame/ prefix in many cases.

  If you encounter linking errors after changing the included sources, delete the static libraries for the subtarget from the build folder. For the previous example on Windows using GCC, these would be in build/mingw-gcc/bin/x64/Release/mame_pacem by default.

- On a system with multiple CPU cores, compilation can be sped up by compiling multiple source files in parallel. This is done with the -j parameter. For instance, make -j5 is a good starting point on a system with a quad-core CPU.

  Note: a good number to start with is the total number of CPU cores in your system plus one. An excessive number of concurrent jobs will increase compilation time, particularly if the compiler jobs exhaust available memory. The optimal number depends on many factors, including number of CPU cores, available RAM, disk and filesystem performance, and memory bandwidth.

- Debugging information can be added to a compile using SYMBOLS=1 though most users will not want or need to use this. This increases compile time and disk space used. Note that a full build of MAME including internal debugging symbols will exceed the maximum size for an executable on Windows, and will not be possible to run without first stripping the symbols.

Putting all of these together, we get a couple of examples:

Rebuilding MAME on a dual-core (e.g. i3 or laptop i5) machine:

    make -j3

Rebuilding MAME for just the Pac-Man and Galaxian families of systems, with tools, on a quad-core (e.g. i5 or i7) machine:

    make SUBTARGET=pacem SOURCES=src/mame/pacman,src/mame/galaxian TOOLS=1 REGENIE=1 -j5

Rebuilding MAME for just the Apple II systems, compiling up to six sources in parallel:

    make SUBTARGET=appulator SOURCES=apple/apple2.cpp,apple/apple2e.cpp,apple/apple2gs.cpp REGENIE=1 -j6

## Microsoft Windows

MAME for Windows is built using the MSYS2 environment. You will need a 64-bit version of Windows 10 1809 or later and a reasonably up-to-date MSYS2 installation. Building for 64-bit ARM (AArch64) requires a 64-bit ARM system running Windows 11 or later.

- By default, MAME will be built using native Windows OS interfaces for window management, audio/video output, font rendering, etc. If you want to use the portable SDL (Simple DirectMedia Layer) interfaces instead, you can add OSD=sdl to the make options. The main emulator binary will have an `sdl` prefix prepended (e.g. `sdlmame.exe`). You will need to install the MSYS2 packages for SDL 2 version 2.0.14 or later.

- By default, MAME will include the native Windows debugger. To also include the portable Qt debugger, add USE_QTDEBUG=1 to the make options. You will need to install the MSYS2 packages for Qt 6.

### Using a standard MSYS2 installation

MAME is built for Windows using a standard MSYS2 installation with additional packages installed to provide the development tools needed for building MAME. These instructions assume you have some familiarity with MSYS2 and the pacman package manager.

- Install the MSYS2 environment from the MSYS2 homepage.

- Install packages necessary to build MAME. At the very least, you’ll need `bash`, `git` and `make`.

- For debugging you may want to install `gdb`.

- To generate API documentation from source, you’ll need `doxygen`.

- If you plan to rebuild bgfx shaders and you want to rebuild the GLSL parser, you’ll need `bison`.

The additional packages you’ll need depend on the CPU architecture you’re building for.

64-bit x86-64 (libstdc++/UCRT)

- You’ll need `mingw-w64-ucrt-x86_64-gcc` and `mingw-w64-ucrt-x86_64-python`.

- To compile using the clang compiler, you’ll also need `mingw-w64-ucrt-x86_64-clang`.

- To use the LLVM linker and archiver (generally much faster than the GNU linker and archiver), you’ll need `mingw-w64-ucrt-x86_64-lld`, `mingw-w64-ucrt-x86_64-llvm-tools`, `mingw-w64-ucrt-x86_64-llvm` and `mingw-w64-ucrt-x86_64-libc++`.

- To build against the portable SDL interfaces, you’ll need `mingw-w64-ucrt-x86_64-SDL2` and `mingw-w64-ucrt-x86_64-SDL2_ttf`.

- To build the Qt debugger, you’ll need `mingw-w64-ucrt-x86_64-qt6-base`.

- To build the HTML user/developer documentation, you’ll need `mingw-w64-ucrt-x86_64-librsvg`, `mingw-w64-ucrt-x86_64-python-sphinx`, `mingw-w64-ucrt-x86_64-python-sphinx_rtd_theme` and `mingw-w64-ucrt-x86_64-python-sphinxcontrib-svg2pdfconverter`.

- To build the PDF documentation, you’ll additionally need `mingw-w64-ucrt-x86_64-texlive-latex-extra` and `mingw-w64-ucrt-x86_64-texlive-fonts-recommended`.

- Open the ucrt64.exe helper from the msys64 installation folder or the MSYS2 UCRT64 shortcut from the start menu to start a Bash shell configured with the correct paths and environment variables.

64-bit x86-64 (libc++/UCRT)

- You’ll need `mingw-w64-clang-x86_64-clang`, `mingw-w64-clang-x86_64-python` and `mingw-w64-clang-x86_64-gcc-compat`.

- To use the LLVM linker and archiver (generally much faster than the GNU linker and archiver), you’ll need `mingw-w64-clang-x86_64-lld`, `mingw-w64-clang-x86_64-llvm-tools`, `mingw-w64-clang-x86_64-llvm` and `mingw-w64-clang-x86_64-libc++`.

- To build against the portable SDL interfaces, you’ll need `mingw-w64-clang-x86_64-SDL2` and `mingw-w64-clang-x86_64-SDL2_ttf`.

- To build the Qt debugger, you’ll need `mingw-w64-clang-x86_64-qt6-base`.

- To build the HTML user/developer documentation, you’ll need `mingw-w64-clang-x86_64-librsvg`, `mingw-w64-clang-x86_64-python-sphinx`, `mingw-w64-clang-x86_64-python-sphinx_rtd_theme` and `mingw-w64-clang-x86_64-python-sphinxcontrib-svg2pdfconverter`.

- To build the PDF documentation, you’ll additionally need `mingw-w64-clang-x86_64-texlive-latex-extra` and `mingw-w64-clang-x86_64-texlive-fonts-recommended`.

- Open the clang64.exe helper from the msys64 installation folder or use the MSYS2 CLANG64 shortcut to start a Bash shell configured with the correct paths and environment variables.

64-bit ARM (libc++/UCRT)

- You’ll need `mingw-w64-clang-aarch64-clang`, `mingw-w64-clang-aarch64-python` and `mingw-w64-clang-aarch64-gcc-compat`.

- To use the LLVM linker and archiver (generally much faster than the GNU linker and archiver), you’ll need `mingw-w64-clang-aarch64-lld`, `mingw-w64-clang-aarch64-llvm-tools`, `mingw-w64-clang-aarch64-llvm` and `mingw-w64-clang-aarch64-libc++`.

- To build against the portable SDL interfaces, you’ll need `mingw-w64-clang-aarch64-SDL2` and `mingw-w64-clang-aarch64-SDL2_ttf`.

- To build the Qt debugger, you’ll need `mingw-w64-clang-aarch64-qt6-base`.

- To build the HTML user/developer documentation, you’ll need `mingw-w64-clangarm64-x86_64-librsvg`, `mingw-w64-clangarm64-x86_64-python-sphinx`, `mingw-w64-clangarm64-x86_64-python-sphinx_rtd_theme` and `mingw-w64-clangarm64-x86_64-python-sphinxcontrib-svg2pdfconverter`.

- It is not currently possible to build the PDF documentation using the CLANGARM64 environment as the TeX Live tools do not work. You may be able to use the UCRT64 or CLANG64 environment to build the PDF documentation on a 64-bit ARM system.

- Open the clangarm64.exe helper from the msys64 installation folder or use the MSYS2 CLANGARM64 shortcut to start a Bash shell configured with the correct paths and environment variables.

32-bit x86

It is no longer possible to compile 32-bit x86 MAME build using an MSYS2 environment. Up-to-date 32-bit versions of GCC exceed the available address space when compiling MAME’s address space classes and Lua bindings. MSYS2 no longer provides 32-bit x86 LLVM and clang packages. To build MAME for 32-bit x86 systems, you must use an environment that allows cross-compiling for a 32-bit target using 64-bit tools (e.g. using a MinGW environment on a Linux system).

### Building with Microsoft Visual Studio

- You can generate Visual Studio 2022 projects using make vs2022. The solution and project files will be created in `build/projects/windows/mame/vs2022` by default (the name of the `build` folder can be changed using the `BUILDDIR` option). This will always regenerate the projects, so REGENIE=1 is not needed.

- Adding MSBUILD=1 to the make options will build the solution using the Microsoft Build Engine after generating the project files. Note that this requires paths and environment variables to be configured so the correct Visual Studio tools can be located; please refer to the Microsoft-provided instructions on using the Microsoft C++ toolset from the command line. You may find it easier to not use MSBUILD=1 and load the project file into Visual Studio’s GUI for compilation.

- The MSYS2 environment is still required to generate the project files, convert built-in layouts, compile UI translations, etc.

### Some notes about the MSYS2 environment

MSYS2 uses the pacman tool from Arch Linux for package management. There is a page on the Arch Linux wiki with helpful information on using the pacman package management tool.

The MSYS2 environment includes two kinds of tools: MSYS2 tools designed to work in a UNIX-like environment on top of Windows, and MinGW tools designed to work in a more Windows-like environment. The MSYS2 tools are installed in `/usr/bin` while the MinGW tools are installed in `/ucrt64/bin`, `/clang64/bin` and/or `/clangarm64/bin` (relative to the MSYS2 installation directory). MSYS2 tools work best in an MSYS2 terminal, while MinGW tools work best in a Microsoft command prompt.

The most obvious symptom of this is that arrow keys don’t work in interactive programs if you run them in the wrong kind of terminal. If you run MinGW gdb or python from an MSYS2 terminal window, command history won’t work and it may not be possible to interrupt an attached program with gdb. Similarly it may be very difficult to edit using MSYS2 vim in a Microsoft command prompt window.

MAME is built using the MinGW compilers, so the MinGW directories are included earlier in the `PATH` environment variable for the build environments. If you want to use an interactive MSYS2 program from an MSYS2 shell, you may need to type the absolute path to avoid using the MinGW equivalent instead.

MSYS2 gdb may have issues debugging MinGW programs like MAME. You may get better results by installing the MinGW version of gdb and running it from a Microsoft command prompt window to debug MAME.

GNU Make supports both POSIX-style shells (e.g. bash) and the Microsoft cmd.exe shell. When using the cmd.exe shell, the `copy` command doesn’t provide a useful exit status, so file copy tasks can fail silently. This may cause your build to appear to succeed while producing incorrect results. The command to link MAME exceeds the maximum command length supported by the cmd.exe shell, so you will not be able to produce a complete build of MAME. As such, we recommend that you do not install MinGW versions of GNU Make, and use the MSYS2 version of GNU Make from the `make` package.

A complete build of MAME including line number symbols exceeds the size limit imposed by the PE file format and cannot be run. Workarounds include including only a subset of the systems supported by MAME, extracting symbols to a separate file and stripping excess symbols from the MAME executable, or compiling MAME using clang with the option to place symbols in external PDB files.

## Fedora Linux

You’ll need a few prerequisites from your Linux distribution. Make sure you get SDL 2 version 2.0.14 or later as earlier versions lack required functionality:

    sudo dnf install git gcc gcc-c++ SDL2-devel SDL2_ttf-devel libXi-devel libXinerama-devel qt6-qtbase-devel expat-devel fontconfig-devel alsa-lib-devel pulseaudio-libs-devel

If you want to use the more efficient LLVM tools for archiving static libraries and linking, you’ll need to install the corresponding packages:

    sudo dnf install lld llvm

Compilation is exactly as described above in All Platforms.

To build the HTML user/developer documentation, you’ll need Sphinx, as well as the theme and the SVG converter:

    sudo dnf install python3-sphinx python3-sphinx_rtd_theme python3-sphinxcontrib-rsvgconverter

The HTML documentation can be built with this command:

    make -C docs html

## Debian and Ubuntu (including Raspberry Pi and ODROID devices)

You’ll need a few prerequisites from your Linux distribution. Make sure you get SDL 2 version 2.0.14 or later as earlier versions lack required functionality:

    sudo apt-get install git build-essential python3 libsdl2-dev libsdl2-ttf-dev libfontconfig-dev libpulse-dev qt6-base-dev qt6-base-dev-tools qtchooser

Compilation is exactly as described above in All Platforms. Note the Ubuntu Linux modifies GCC to enable the GNU C Library “fortify source” feature by default, which may cause issues compiling MAME (see Known Issues).

## Arch Linux

You’ll need a few prerequisites from your distro:

    sudo pacman -S base-devel git sdl2_ttf python libxinerama libpulse alsa-lib qt6-base

Compilation is exactly as described above in All Platforms.

## Apple macOS

You’ll need a few prerequisites to get started. Make sure you’re on macOS 11.0 Big Sur or later. You will need SDL 2 version 2.0.14 or later. You’ll also need to install Python 3 – it’s currently included with the Xcode command line tools, but you can also install a stand-alone version or get it via the Homebrew package manager.

- Install Xcode from the Mac App Store or ADC (AppleID required).

- To find the corresponding Xcode for your MacOS release please visit xcodereleases.com to find the latest version of Xcode available to you.

- Launch Xcode. It will download a few additional prerequisites. Let this run through before proceeding.

- Once that’s done, quit Xcode and open a Terminal window.

- Type xcode-select --install to install additional tools necessary for MAME (also available as a package on ADC).

Next you’ll need to get SDL 2 installed.

- Go to this site and download the macOS .dmg file

- If the .dmg doesn’t open automatically, 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. You will have to authenticate with your user password.

If you don’t already have it, get Python 3 set up:

- Go to the official Python site, navigate to the releases for macOS, and click the link to download the installer for the latest stable release (this was Python 3.10.4 at the time of writing).

- Scroll down to the “Files” section, and download the macOS version (called “macOS 64-bit universal2 installer” or similar).

- Once the package downloads, open it and follow the standard installation process.

Finally to begin compiling, use Terminal to navigate to where you have the MAME source tree (cd command) and follow the normal compilation instructions from above in All Platforms.

## Emscripten Javascript and HTML

First, download and install Emscripten 3.1.35 or later by following the instructions at the official site.

Once Emscripten has been installed, it should be possible to compile MAME out-of-the-box using Emscripten’s emmake tool. Because a full MAME compile is too large to load into a web browser at once, you will want to use the SOURCES parameter to compile only a subset of the project, e.g. (in the MAME directory):

    emmake make SUBTARGET=pacmantest SOURCES=src/mame/pacman/pacman.cpp

The SOURCES parameter should have the path to at least one driver .cpp file. The make process will attempt to locate and include all dependencies necessary to produce a complete build including the specified driver(s). However, sometimes it is necessary to manually specify additional files (using commas) if this process misses something. e.g.

    emmake make SUBTARGET=apple2e SOURCES=src/mame/apple/apple2e.cpp,src/devices/machine/applefdc.cpp

The value of the SUBTARGET parameter serves only to differentiate multiple builds and need not be set to any specific value.

Emscripten supports compiling to WebAssembly with a JavaScript loader instead of all-JavaScript, and in later versions this is actually the default. To force WebAssembly on or off, add WEBASSEMBLY=1 or WEBASSEMBLY=0 to the make command line, respectively.

Other make parameters can also be used, e.g. -j for multithreaded compilation as described earlier.

When the compilation reaches the emcc phase, you may see a number of "unresolved symbol" warnings. At the moment, this is expected for OpenGL-related functions such as glPointSize. Any others may indicate that an additional dependency file needs to be specified in the SOURCES list. Unfortunately this process is not automated and you will need to search the source tree to locate the files supplying the missing symbols. You may also be able to get away with ignoring the warnings if the code path referencing them is not used at run-time.

If all goes well, a .js file will be output to the current directory. This file cannot be run by itself, but requires an HTML loader to provide it with a canvas to draw to and to pass in command-line parameters. The Emularity project provides such a loader.

There are example .html files in that repository which can be edited to point to your newly compiled MAME .js file and pass in whatever parameters you desire. You will then need to place all of the following on a web server:

- The compiled MAME .js file

- The compiled MAME .wasm file if using WebAssembly

- The .js files from the Emularity package (loader.js, browserfs.js, etc.)

- A .zip file with the ROMs for the MAME driver you would like to run (if any)

- Any software files you would like to run with the MAME driver

- An Emularity loader .html modified to point to all of the above

You need to use a web server instead of opening the local files directly due to security restrictions in modern web browsers.

If the result fails to run, you can open the Web Console in your browser to see any error output which may have been produced (e.g. missing or incorrect ROM files). A “ReferenceError: foo is not defined” error most likely indicates that a needed source file was omitted from the SOURCES list.

## Compiling the Documentation

Compiling the documentation will require you to install several packages depending on your operating system.

### Compiling the Documentation on Microsoft Windows

On Windows, you’ll need a couple of packages from the MSYS2 environment. You can install these packages with

    pacman -S mingw-w64-x86_64-librsvg mingw-w64-x86_64-python-sphinx mingw-w64-x86_64-python-sphinxcontrib-svg2pdfconverter

If you intend to make a PDF via LaTeX, you’ll need to install a LaTeX distribution such as TeX Live:

    pacman -S mingw-w64-x86_64-texlive-fonts-recommended mingw-w64-x86_64-texlive-latex-extra

### Compiling the Documentation on Debian and Ubuntu

On Debian/Ubuntu flavors of Linux, you’ll need python3-sphinx/python-sphinx and the python3-pip/python-pip packages:

    sudo apt-get install python3-sphinx python3-pip
    pip3 install sphinxcontrib-svg2pdfconverter

On Debian, you’ll need to install the librsvg2-bin package:

    sudo apt-get install librsvg2-bin

If you intend to make a PDF via LaTeX, you’ll need to install a LaTeX distribution such as TeX Live:

    sudo apt-get install librsvg2-bin latexmk texlive texlive-science texlive-formats-extra

From this point you can do `make html` or `make latexpdf` from the docs folder to generate the output of your choice. Typing `make` by itself will tell you all available formats. The output will be in the docs/build folder in a subfolder based on the type chosen (e.g. `make html` will create docs/build/html with the output.)

## Useful Options

This section summarises some of the more useful options recognised by the main makefile. You use these options by appending them to the make command, setting them as environment variables, or adding them to your prefix makefile. Note that in order to apply many of these settings when rebuilding, you need to set REGENIE=1 the first time you build after changing the option(s). Also note that GENie does not automatically rebuild affected files when you change an option that affects compiler settings.

### Overall build options

PREFIX_MAKEFILE

  Name of a makefile to include for additional options if found (defaults to useroptions.mak). May be useful if you want to quickly switch between different build configurations.

BUILDDIR

  Set to change the name of the subfolder used for project files, generated sources, object files, and intermediate libraries (defaults to build).

REGENIE

  Set to 1 to force project files to be regenerated.

VERBOSE

  Set to 1 to show full commands when using GNU Make as the build tool. This option applies immediately without needing regenerate project files.

IGNORE_GIT

  Set to 1 to skip the working tree scan and not attempt to embed a Git revision description in the version string.

### Tool locations

OVERRIDE_CC

  Set the C/Objective-C compiler command. (This sets the target C compiler command when cross-compiling.)

OVERRIDE_CXX

  Set the C++/Objective-C++ compiler command. (This sets the target C++ compiler command when cross-compiling.)

OVERRIDE_LD

  Set the linker command. This is often not necessary or useful because the C or C++ compiler command is used to invoke the linker. (This sets the target linker command when cross-compiling.)

OVERRIDE_AR

  Set static library archiver command.

PYTHON_EXECUTABLE

  Set the Python interpreter command. You need Python 3.2 or later to build MAME.

CROSS_BUILD

  Set to 1 to use separate host and target compilers and linkers, as required for cross-compilation. In this case, OVERRIDE_CC, OVERRIDE_CXX and OVERRIDE_LD set the target C compiler, C++ compiler and linker commands, while CC, CXX and LD set the host C compiler, C++ compiler and linker commands.

### Including subsets of supported systems

SUBTARGET

  Set emulator subtarget to build. Some pre-defined subtargets are provided, using Lua scripts in scripts/target/mame and system driver filter files in src/mame. User-defined subtargets can be created using the SOURCES or SOURCEFILTER option.

SOURCES

  Specify system driver source files and/or folders to include. Usually used in conjunction with the SUBTARGET option. Separate multiple files/folders with commas.

SOURCEFILTER

  Specify a system driver filter file. Usually used in conjunction with the SUBTARGET option. The filter file can specify source files to include system drivers from, and individual system drivers to include or exclude. There are some example system driver filter files in the src/mame folder.

### Optional features

TOOLS

  Set to 1 to build additional tools along with the emulator, including unidasm, chdman, romcmp, and srcclean.

EMULATOR

  When set to 0, the main emulator target will not be created. This is intended to be used in conjunction with setting TOOLS to 1 to build the additional tools without building the emulator.

NO_OPENGL

  Set to 1 to disable building the OpenGL video output module.

NO_USE_PORTAUDIO

  Set to 1 to disable building the PortAudio sound output module and the PortAudio library.

NO_USE_PULSEAUDIO

  Set to 1 to disable building the PulseAudio sound output module on Linux.

USE_WAYLAND

  Set to 1 to include support for bgfx video output with the Wayland display server.

USE_TAPTUN

  Set to 1 to include the tap/tun network module, or set to 0 to disable building the tap/tun network module. The tap/tun network module is included by default on Windows and Linux.

USE_PCAP

  Set to 1 to include the pcap network module, or set to 0 to disable building the pcap network module. The pcap network module is included by default on macOS and NetBSD.

USE_QTDEBUG

  Set to 1 to include the Qt debugger on platforms where it’s not built by default (e.g. Windows or macOS), or to 0 to disable it. You’ll need to install Qt development libraries and tools to build the Qt debugger. The process depends on the platform.

### Compilation options

NOWERROR

  Set to 1 to disable treating compiler warnings as errors. This may be needed in marginally supported configurations.

DEPRECATED

  Set to 0 to disable deprecation warnings (note that deprecation warnings are not treated as errors).

DEBUG

  Set to 1 to enable runtime assertion checks and additional diagnostics. Note that this has a performance cost, and is most useful for developers.

OPTIMIZE

  Set optimisation level. The default is 3 to favour performance at the expense of larger executable size. Set to 0 to disable optimisation (can make debugging easier), 1 for basic optimisation that doesn’t have a space/speed trade-off and doesn’t have a large impact on compile time, 2 to enable most optimisation that improves performance and reduces size, or s to enable only optimisations that generally don’t increase executable size. The exact set of supported values depends on your compiler.

SYMBOLS

  Set to 1 to include additional debugging symbols over the default for the target platform (many target platforms include function name symbols by default).

SYMLEVEL

  Numeric value that controls the level of detail in debugging symbols. Higher numbers make debugging easier at the cost of increased build time and executable size. The supported values depend on your compiler. For GCC and similar compilers, 1 includes line number tables and external variables, 2 also includes local variables, and 3 also includes macro definitions.

PDB_SYMBOLS

  Set to 1 to generate CodeView format symbols in separate PDB files, allowing source-level debugging using Microsoft Visual Studio or WinDbg. It can also be used with other tools that can load symbols from PDB files, e.g. the Intel VTune and AMD µProf performance analysis tools. This option is only supported for MinGW builds using the clang compiler and the LLVM linker (lld). This option only takes effect if the SYMBOLS option is set to a non-zero value.

ARCHOPTS

  Additional command-line options to pass to the compiler and linker. This is useful for supplying code generation or ABI options, for example to enable support for optional CPU features.

ARCHOPTS_C

  Additional command-line options to pass to the compiler when compiling C source files.

ARCHOPTS_CXX

  Additional command-line options to pass to the compiler when compiling C++ source files.

ARCHOPTS_OBJC

  Additional command-line options to pass to the compiler when compiling Objective-C source files.

ARCHOPTS_OBJCXX

  Additional command-line options to pass to the compiler when compiling Objective-C++ source files.

### Library/framework locations

SDL_INSTALL_ROOT

  SDL installation root directory for shared library style SDL.

SDL_FRAMEWORK_PATH

  Search path for SDL framework.

USE_LIBSDL

  Set to 1 to use shared library style SDL on targets where framework is default.

USE_SYSTEM_LIB_ASIO

  Set to 1 to prefer the system installation of the Asio C++ asynchronous I/O library over the version provided with the MAME source.

USE_SYSTEM_LIB_EXPAT

  Set to 1 to prefer the system installation of the Expat XML parser library over the version provided with the MAME source.

USE_SYSTEM_LIB_ZLIB

  Set to 1 to prefer the system installation of the zlib data compression library over the version provided with the MAME source.

USE_SYSTEM_LIB_ZSTD

  Set to 1 to prefer the system installation of the Zstandard data compression library over the version provided with the MAME source.

USE_SYSTEM_LIB_JPEG

  Set to 1 to prefer the system installation of the libjpeg image compression library over the version provided with the MAME source.

USE_SYSTEM_LIB_FLAC

  Set to 1 to prefer the system installation of the libFLAC audio compression library over the version provided with the MAME source.

USE_SYSTEM_LIB_LUA

  Set to 1 to prefer the system installation of the embedded Lua interpreter over the version provided with the MAME source.

USE_SYSTEM_LIB_SQLITE3

  Set to 1 to prefer the system installation of the SQLITE embedded database engine over the version provided with the MAME source.

USE_SYSTEM_LIB_PORTMIDI

  Set to 1 to prefer the system installation of the PortMidi library over the version provided with the MAME source.

USE_SYSTEM_LIB_PORTAUDIO

  Set to 1 to prefer the system installation of the PortAudio library over the version provided with the MAME source.

USE_SYSTEM_LIB_UTF8PROC

  Set to 1 to prefer the system installation of the Julia utf8proc library over the version provided with the MAME source.

USE_SYSTEM_LIB_GLM

  Set to 1 to prefer the system installation of the GLM OpenGL Mathematics library over the version provided with the MAME source.

USE_SYSTEM_LIB_RAPIDJSON

  Set to 1 to prefer the system installation of the Tencent RapidJSON library over the version provided with the MAME source.

USE_SYSTEM_LIB_PUGIXML

  Set to 1 to prefer the system installation of the pugixml library over the version provided with the MAME source.

## Known Issues

### GNU C Library fortify source feature

The GNU C Library has options to perform additional compile- and run-time checks on string operations, enabled by defining the `_FORTIFY_SOURCE` preprocessor macro. This is intended to improve security at the cost of a small amount of overhead. MAME is not secure software, and we do not support building with `_FORTIFY_SOURCE` defined.

Some Linux distributions (including Gentoo and Ubuntu) have patched GCC to define `_FORTIFY_SOURCE` to `1` as a built-in macro. This is problematic for more projects than just MAME, as it makes it hard to disable the additional checks (e.g. if you don’t want the performance impact of the run-time checks), and it also makes it hard to define `_FORTIFY_SOURCE` to `2` if you want to enable stricter checks. You should really take it up with the distribution maintainers, and make it clear you don’t want non-standard GCC behaviour. It would be better if these distributions defined this macro by default in their packaging environments if they think it’s important, rather than trying to force it on everything compiled on their distributions. (This is what Red Hat does: the `_FORTIFY_SOURCE` macro is set in the RPM build environment, and not by distributing a modified version of GCC.)

If you get compilation errors in `bits/string_fortified.h` you should first ensure that the `_FORTIFY_SOURCE` macro is defined via the environment (e.g. a CFLAGS or CXXFLAGS environment variable). You can check to see whether the `_FORTIFY_SOURCE` macro is a built-in macro with your version of GCC with a command like this:

gcc -dM -E - < /dev/null | grep _FORTIFY_SOURCE

If `_FORTIFY_SOURCE` is defined to a non-zero value by default, you can work around it by adding -U_FORTIFY_SOURCE to the compiler flags (e.g. by using the ARCHOPTS setting, or setting the CFLAGS and CXXFLAGS environment variables.

### Issues affecting MinGW clang

MinGW clang and llvm can give spurious undefined symbol errors when linking using CodeView format symbols with high symbol detail levels. If you encounter undefined symbol errors when linking with PDB_SYMBOLS=1 to produce CodeView format symbols, try setting SYMLEVEL=1 to reduce the symbol detail level (line number tables will still be included, but local variables will be omitted).

### Issues affecting Microsoft Visual Studio

The MSVC compiler produces spurious warnings about potentially uninitialised local variables. You currently need to add `NOWERROR=1` to the options passed to make when generating the Visual Studio project files. This stops warnings from being treated as errors. (MSVC seems to lack options to control which specific warnings are treated as errors, which other compilers support.)

## Unusual Build Configurations

### Linking using the LLVM linker

The LLVM linker is generally faster than the GNU linker that GCC uses by default. This is more pronounced on systems with a high overhead for file system operations (e.g. Microsoft Windows, or when compiling on a disk mounted over a network). To use the LLVM linker with GCC, ensure the LLVM linker is installed and add `-fuse-ld=lld` to the linker options (e.g. in the LDFLAGS environment variable or in the ARCHOPTS setting).

### Creating static libraries using the LLVM archiver

The LLVM archiver is generally faster than the GNU archiver that is used by default. This is more pronounced on systems with a high overhead for file system operations (e.g. Microsoft Windows, or when compiling on a disk mounted over a network). To use the LLVM archiver, ensure the LLVM archiver is installed and add `OVERRIDE_AR=llvm-ar` to the options passed to make when generating the project files.

### Cross-compiling MAME

MAME’s build system has basic support for cross-compilation. Set CROSS_BUILD=1 to enable separate host and target compilers, set OVERRIDE_CC and OVERRIDE_CXX to the target C/C++ compiler commands, and if necessary set CC and CXX to the host C/C++ compiler commands. If the target OS is different to the host OS, set it with TARGETOS. For example it may be possible to build a MinGW32 x64 build on a Linux host using a command like this:

    make TARGETOS=windows PTR64=1 OVERRIDE_CC=x86_64-w64-mingw32-gcc OVERRIDE_CXX=x86_64-w64-mingw32-g++ OVERRIDE_LD=x86_64-w64-mingw32-ld MINGW64=/usr**

(The additional packages required for producing a standard MinGW32 x64 build on a Fedora Linux host are `mingw64-gcc-c++`, `mingw64-winpthreads-static` and their dependencies. Non-standard builds may require additional packages.)

### Using libc++ on Linux

MAME may be built using the LLVM project’s “libc++” C++ Standard Library. The prerequisites are a working clang/LLVM installation, and the libc++ development libraries. On Fedora Linux, the necessary packages are libcxx, libcxx-devel, libcxxabi and libcxxabi-devel. Set the C and C++ compiler commands to use clang, and add -stdlib=libc++ to the C++ compiler and linker options. You could use a command like this:

    env LDFLAGS=-stdlib=libc++ make OVERRIDE_CC=clang OVERRIDE_CXX=clang++ ARCHOPTS_CXX=-stdlib=libc++ ARCHOPTS_OBJCXX=-stdlib=libc++

The options following the make command may be placed in a prefix makefile if you want to use this configuration regularly, but LDFLAGS needs to be be set in the environment.

### Using a GCC/GNU libstdc++ installation in a non-standard location on Linux

GCC may be built and installed to a custom location, typically by supplying the --prefix= option to the configure command. This may be useful if you want to build MAME on a Linux distribution that still uses a version of GNU libstdc++ that predates C++20 support. To use an alternate GCC installation to build MAME, set the C and C++ compilers to the full paths to the gcc and g++ commands, and add the library path to the run-time search path. If you installed GCC in /opt/local/gcc72, you might use a command like this:

    make OVERRIDE_CC=/opt/local/gcc72/bin/gcc OVERRIDE_CXX=/opt/local/gcc72/bin/g++ ARCHOPTS=-Wl,-R,/opt/local/gcc72/lib64

You can add these options to a prefix makefile if you plan to use this configuration regularly.