Retro68: a GCC cross-compiler for 68K and PowerPC Macs

Why a cross-compiler for the classic Mac exists

Retro68 is described as a GCC-based cross-compilation environment for 68K and PowerPC Macs. The reason given in the README is blunt: there is no decent C++ compiler targeting Apple's System 6. And then a note for anyone who is not sure this is for them: if that is not a sufficient reason, you will find something more useful elsewhere.

That is the entire market. The classic Macintosh ran System 6 and System 7 on 68000 processors and later Mac OS on PowerPC, and the development toolchain of the era, CodeWarrior and the Macintosh Programmer's Workshop, are long gone from easy reach. Retro68 exists so that a modern compiler can target those machines, which means you can write code in a current language, with a current standard library, and produce a binary that a 1994 Macintosh will run.

The two targets are genuinely different. The 68K build targets the older machines and the System 6 and 7 era APIs, and the PowerPC build targets the later Macs. The repository has separate build directories for them, and the README's build options include a --no-carbon flag, which points at the third variant: the Carbon API layer, the framework Apple introduced to bridge the classic APIs to the new ones, available on the PowerPC side.

The primary language of the repository is C, and the licence is GPL-3.0, which for a GCC-derived toolchain is the expected and in practice required choice.

Prerequisites and the platform package lists

The prerequisite list is long, which is what building a GCC looks like.

You need Linux, Mac OS X or Windows via Cygwin. Then boost, CMake 3.9 or later, and the GCC dependencies, which are GMP 4.2 or later, MPFR 2.3.1 or later and MPC 0.8.0 or later. Then bison 3.0.2 or later, ruby 2.1 or later, flex and texinfo. The recommended item is the Apple Universal Interfaces at version 3.x, with 3.4 the tested version. And the README ends the list with something that is not a package at all: an ancient Mac and/or an emulator.

The per-distribution package lists are the fastest way to get those in place. On Ubuntu.

sudo apt-get install cmake libgmp-dev libmpfr-dev libmpc-dev libboost-all-dev bison flex texinfo ruby

On Arch Linux.

sudo pacman -S --needed cmake gmp mpfr libmpc boost bison flex texinfo ruby

On a Mac with Homebrew.

brew install boost cmake gmp mpfr libmpc bison texinfo

And there is a special case worth reading, because it is a genuinely unusual build environment. You can run Retro68 on a PowerMac G4 or G5 running Mac OS 10.4, Tiger, using the tigerbrew package manager, and then the host compiler is the one you installed there.

brew install gcc cmake gmp mpfr libmpc bison texinfo
brew install boost --c++11

The bootstrap is the interesting part. Bootstrapping a modern GCC on a system whose own compiler is from 2004 is exactly the situation where a working host toolchain matters, and the boost package there needs the C++11 flag for the same reason.

Building the toolchain and the build options

The clone needs the recursive option, because the repository uses submodules.

git submodule update --init

To get the latest changes afterwards, a pull is followed by a submodule update as well, so the two stay in step.

git pull
git submodule update

The build itself is a single script run from a build directory beside the source tree.

mkdir ../Retro68-build
cd ../Retro68-build
../Retro68/build-toolchain.bash

The toolchain is installed into a toolchain directory inside the build directory, with all the commands in toolchain/bin, so you will want that on your PATH.

There is one more option, for the Tiger case, where you tell the build script which host compiler to use rather than the default.

../Retro68/build-toolchain.bash --host-cxx-compiler=g++-7 --host-c-compiler=gcc-7

The README is candid about the cost. Building all of Retro68 involves building binutils and GCC twice, so it takes quite a while, and the two builds are the host tools and the cross tools.

That cost is what the build options are for. The --no-68k, --no-ppc and --no-carbon flags limit the build to the targets you actually want, and --no-ppc implies --no-carbon. A developer who only cares about the oldest machines can skip the PowerPC half of the build entirely, which is roughly half the wait.

For incremental work there is --skip-thirdparty, which skips gcc and binutils and compiles only the Retro68-specific tools, libraries and sample programs. The build-host, build-target, build-target-ppc and build-target-carbon directories are CMake build directories generated from the top-level CMakeLists.txt, so you can also cd into one and run make separately.

Universal Interfaces versus Multiversal Interfaces

To compile for the Mac you need header files and libraries describing the APIs, and there are two possible sources, which is the sharpest practical decision in the project.

The Multiversal Interfaces are included with Retro68 out of the box and are free software. However, they are incomplete and may still contain serious bugs, and the missing things include Carbon, MacTCP, OpenTransport, Navigation Services, and basically everything introduced after System 7.0.

Apple's Universal Interfaces used to be a free download from Apple, but they have taken the site offline and the licence agreement does not allow redistribution, which is why they are not in the repository. The README then makes a point about fair use: keeping it available for reasons of historical interest might be covered, or might not, and the author adds that he is not a lawyer. If you find a copy, you can put it inside the InterfacesAndLibraries directory in the source tree, and version 3.4 has received the most testing, though any 3.x version could theoretically work. The exact directory layout inside that directory does not matter, since it is picked up automatically when Retro68 is built.

There is a platform-specific gotcha here. Especially on non-macOS platforms, make sure that the Mac resource fork of the PowerPC library files is included in a format recognized by Retro68. The recognised formats are MacBinary II, for example Interfacelib.bin, AppleDouble, either ._InterfaceLib or %InterfaceLib, or a Basilisk and SheepShaver resource fork at .rsrc/InterfaceLib.

That is the cost of using a resource-fork-based file format on a filesystem that does not have resource forks, and the practical fix is to convert the files before copying them across.

Nix shells and the Docker route

The README notes there is now experimental support for the Nix Package Manager and, with a certain amount of advocacy, suggests that maybe you should be using it.

The usage is short. Once you have nix installed, and without checking out the Retro68 repository, you can run a development shell from the Retro68 directory.

nix develop github:autc04/Retro68#m68k

That gives you a shell with the compiler tools targeting 68K Macs available in the path, and CC and the other environment variables already set up for you. You can then cd to one of the example directories or to your own project and use cmake to build it.

The PowerPC equivalent is a different attribute.

nix develop github:autc04/Retro68#powerpc

The repository backs this up with a flake.nix and flake.lock, a default.nix, an .envrc for direnv, a garnix.yaml and a nix/ directory, so the Nix integration is a first-class part of the tree rather than an afterthought.

The Docker route exists as well, and the Dockerfile is a three-stage build on Ubuntu 22.04. The base stage installs the same package set, the build stage runs the toolchain build script, and the release stage copies the toolchain out.

FROM ubuntu:22.04 AS base
ENV PATH=/Retro68-build/toolchain/bin:$PATH

The release image also carries the scripts for preparing headers and resource includes, installing the Universal Interfaces and the docker entrypoint, so the image can be used to build programs against a chosen interface set without a host checkout. There is a TODO in the README about documenting the binary cache that would avoid builds altogether, which tells you that part of the Nix story is unfinished.

Where Retro68 is the wrong choice

The first limitation is the API coverage of the bundled interfaces, and it is the one that decides whether the project is usable for you. The Multiversal Interfaces are incomplete and may still contain serious bugs, and what is missing includes Carbon, MacTCP, OpenTransport, Navigation Services and basically everything introduced after System 7.0. A project that needs networking through MacTCP, or the Navigation Services for location, or Carbon, either finds an open source route outside this project or requires the Universal Interfaces from an unofficial source.

The second is the build time. Building binutils and GCC twice is a long process on a normal machine, and the README says so directly. The --no-68k, --no-ppc and --no-carbon flags mitigate it, and --skip-thirdparty helps for incremental work, but a first build is a substantial commitment.

The third is that the host toolchain is a prerequisite, not a convenience. On a Tiger PowerMac, the entire exercise depends on a package manager that still works there, and on the boost install needing the C++11 flag. Cross-compiling for old hardware from old hardware is a legitimate activity, and this is a rarer and more demanding version of it.

The fourth is the Cygwin route, where the README warns that compilation via Cygwin is around three times slower than other platforms. The list of Cygwin packages to select is long, including bison, cmake, flex, gcc-core, gcc-g++, libboost-devel, libgmp-devel, libmpc-devel, libmpfr-devel, make, texinfo and zlib-devel, and additional dependencies are installed automatically.

The fifth is the age of the release tags. The published releases are v2019.8.2 from August 2019 and v2019.8 from two days earlier, with a version scheme based on the date. The repository is not archived and the last push was on 2026-10-16, so the code is being worked on even though the tags are old, and the actual state of the tree is what you would be building.

Licence, maintenance and the shape of a cross-compilation environment

The project is under the GPL-3.0 licence, with the COPYING file at the root and a separate COPYING.RUNTIME alongside it. The runtime licence being distinct matters in a toolchain, because it governs what you can do with the binaries you produce as opposed to the tools that produce them.

The repository is not archived and the last push was on 2026-10-16, so the toolchain is actively maintained even though the release tags are from 2019. The author signs the README with an email address and invites contact from anyone crazy enough to try it, which is a fair description of the audience.

The repository layout is the interesting part, because it shows the whole pipeline. There are the gcc/ and binutils/ directories with the patches documented separately in GCC-PATCHES.md and BINUTILS-PATCHES.md, which tells you that the approach is to carry local patches to the upstream compilers rather than to fork them wholesale. There is libelf/ and Elf2Mac/ for converting ELF objects into the Mac format, ImportLibraries/ and InterfacesAndLibraries/ for the interface side, and a ResourceFiles/ directory alongside Rez/ for the resource fork handling, with ConvertObj/ and ConvertDiskImage/ for the file formats. LaunchAPPL/ is the Mac application launcher, Console/ and PEFTools/ are the command line tools, and libretro/ is a port target.

The Samples/ directory is the best guide to what is possible, with HelloWorld, Dialog, Launcher, MPWTool, NDRV for the driver, Raytracer, SharedLibrary, SystemExtension and WDEF. There is also an AutomatedTests/ directory and a TestApps/ directory, which is a reasonable sign for a project with this much machinery.

The cost of a cross-compilation environment is the maintenance of the patches and the interface handling, and the reward is that a modern toolchain exists for a platform that has been abandoned by every commercial vendor.

Editorial conclusion

Retro68 suits a developer who wants to write modern C++ against the classic Mac APIs and run the result on real hardware or an emulator, since it is a rare maintained route to a recent compiler for those targets. It does not suit a quick experiment, because the toolchain build compiles binutils and GCC twice. Check the Multiversal Interfaces coverage for the APIs you need first, since Carbon and the networking stacks are the parts the README says are missing.

Frequently asked questions

Official sources

1. autc04/Retro68 on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases