How to SWEB on your Mac with OS X

Posted on Fri 14 August 2015 • Tagged with University


I initially used a Macbook Air as my main machine for university work and therefore also for the Operating Systems course. Now, you will probably be aware of this, but the Air is not the fastest laptop in town. Given that it was necessary to run the SWEB, the given operating system via qemu in a Linux virtual machine, things were already quite slow.

Furthermore, testing my group’s Swapping implementation was one of the slowest things I came across and I desperately wanted to work with a faster setup. I learned that at one point in the past SWEB had been compilable and runable on OS X.

I even stumbled across Stefan‘s build scripts on the SWEB wiki. Those were written for a system that had been migrated from several older versions all the way to OS 10.6. My machine had 10.7 as of the time of my first trials and there was no more Apple provided build of gcc available since Apple had moved on to use clang as part of their switch to LLVM.

Back then I spent two evenings with Thomas trying to get a cross compiler up and running to compile on OS X. We failed on that. Soon after that I spent some time together with Daniel who is the main person responsible for the Operating System practicals and we managed to successfully and reproducably build a working cross compiler. With that, one could build and run SWEB on OS X. Some modifications to the build scripts as well as minor modifications to the code base were necessary, but after writing those patches, one could check out and build the system provided by the IAIK.

And, well… I didn’t take the course that year, the course staff updated things in the code base and nobody bothered to check if the Mac build was indeed still building. Suffice to say another round of small fixes was required and I sat together with Daniel again. He’s the expert, I’m just the motivated Mac guy. I was asked whether I’d finally try the course again, given that I’m preparing the Mac build again. My answer was that I’d do so if we get it working before the term started and we did, so there’s that.


  • Xcode
  • Xcode command line tools
  • git (included in Xcode command line tools)
  • homebrew
  • homebrew: tap ghostlyrics/homebrew-sweb
  • homebrew: packages: cloog, qemu, cmake, sweb-gcc

Feel free to skip ahead to the next section if you know how to install those things.


Download and install Xcode from Apple. If you don’t have differing requirements, the stable version is strongly suggested.

Xcode command line tools

Apple stopped shipping its command line tools by default with Xcode. These are necessary to build things with our third party package manager of choice, homebrew. Install them via the wizard triggered by the following command in

xcode-select --install


Unfortunately OS X does not ship with a package manager. Such a program is quite helpful navigating the world of open source software – we use homebrew to install the dependencies of SWEB as well as the cross compiler I have prepared with extensive help from Daniel.

Install homebrew via the instructions at their site - it’s easy. Again, you’re instructed to paste one line into


Since the main architecture your SWEB runs on is i686-linux-gnu you will need a toolchain that builds its executables for said architecture.

To activate the package source enter the following command:

brew tap ghostlyrics/homebrew-sweb

Though an interesting experiment, we did not bother using a clang based toolchain since SWEB does not compile and run well on Linux with clang. Therefore it would’ve been a twofold effort to:

  1. make SWEB build with clang on Linux
  2. build a clang based cross-compiler

packages: cloog, qemu, cmake, sweb-gcc

To install the necessary packages enter the following command:

brew install sweb-gcc qemu cmake cloog

The cross-compiler we provide is based on gcc Version 4.9.1 and precompiled packages are (mostly) available for the current stable version of OS X. Should it be necessary or should you wish to compile it yourself, expect compile times of more than 10 minutes (Model used for measurement: Macbook Pro, 15-inch, Late 2013, 2,3 GHz Intel Core i7, 16 GB 1600 MHz DDR3).

Compiling your first build

You are now ready to compile your first build. Due to problems with in-source builds in the past, SWEB does no longer support those. You will need to build in a different folder, e.g. build:

git clone
mkdir build
cd build
cmake ../sweb
make qemu

After running these commands you should see many lines with different colors in your main Terminal and a second window with the qemu emulator running your SWEB.

Speeding things up

While the way described in the previous section is certainly enough to get you started there a some things you can do to make your workflow speedier.

  • Compiling with more threads enabled
  • Using one command to do several things in succession
  • Chaining your commands
  • Using a RAM disk

Compile with more threads

Using a command line option for make allows you to either specify the amount of threads the program should use for the compilation process or instruct it to be “greedy” and use as many as it sees fit.


The downside to this is that since the process is not threadsafe, your terminal output will be quite messy.

Use one command to do several things

SWEB ships with a very handy make target called mrproper. This script deletes your intermediate files and runs cmake SOURCEFOLDER again. Since you need to run the cmake command for every new file you want to add, this can save some time.

make mrproper
... [Y/n]

When asked whether you want to really do this, some popular UNIX tools allow you to hit ENTER to accept the suggestion in capital letters; the same behaviour is enabled for this prompt.

Chaining your commands

You probably already know this, but shell commands can be chained. Use && to run the next command only if the previous command succeeded and use ; to run the next command in any case.

cmake . && make -j && make qemu
make -j && make qemu ; make clean

Using this technique you can simply build and run with two button presses: The arrow key up to jump through your shell history and the ENTER key to accept.

Using a RAM disk

Since you will be writing and reading a lot of small files again and again and again from your disk, it might be beneficial for both performance as well as disk health to have at least your build folder in a virtual disk residing completely in your RAM. Personally I have not done that, but since the course staff recommends that, instructions can be found here.

If you are not sure the performance differs a lot, has a nice chart buried in their article, graphing the difference between a SSD and a RAM disk. To quote their post:

As you can see, RAM Disks can offer power users an amazing level of performance, but it cannot be stressed enough the dangers of using volatile memory for data storage.

To enable a RAM volume enter the following command:

# NAME: the name you want to assign, SIZE: 2048 * required amount of MegaBytes
diskutil erasevolume HFS+ 'NAME' `hdiutil attach -nomount ram://SIZE`

If you prefer a GUI for this task, the original author of this tip offers one free of charge.

Please make sure you always, always commit AND push your work if you’re working in RAM. Changes will be lost on computer shutdown, crash, freeze, etc.

Changes are preserved during sleep and hibernate. ~Daniel


Working on OS X natively when developing SWEB is indeed possible for the usual use case. Developing and testing architectures different from i686 however, e.g. the 64-bit build or ARM builds will still require you to use Linux (or asking your group members to work on those parts).

How to SWEB on your Mac with OS X is part 2 of Working on SWEB for the Operating Systems course:

  1. SWEB, qemu and a Macbook Air
  2. How to SWEB on your Mac with OS X
  3. Tools and their experiences with SWEB
  4. Retaining your sanity while working on SWEB