There's a similar question about running breakout on Linux variants: Can't run Breakout outside of appliance

My question is specifically about compiling breakout (and hence SPL) on Mac OS X.

So far I have tried running make in the source directory, but the compiler complains that the SPL (spl/lib/libcs.a) is not built for the current architecture, e.g.:

MacBook-Pro:Breakout luke$ make
clang -ggdb3 -Ispl/include -O0 -std=c99 -Wall -Werror -Wno-unused-variable -o breakout breakout.c -Lspl/lib -lcs -lm
ld: warning: ignoring file spl/lib/libcs.a, file was built for archive which is not the architecture being linked (x86_64): spl/lib/libcs.a
Undefined symbols for architecture x86_64:
  "_add", referenced from:
      _main_ in breakout-a98e8b.o
      _initBricks in breakout-a98e8b.o
      _initBall in breakout-a98e8b.o
      _initPaddle in breakout-a98e8b.o
      _initScoreboard in breakout-a98e8b.o
      _initLives in breakout-a98e8b.o
  "_closeGWindow", referenced from:
  _main_ in breakout-a98e8b.o
  "_getEventType", referenced from:
      _main_ in breakout-a98e8b.o
  "_getGObjectAt", referenced from:
      _detectCollision in breakout-a98e8b.o
  "_getHeightGeneric", referenced from:
      _updateScoreboard in breakout-a98e8b.o
  "_getNextEvent", referenced from:
      _main_ in breakout-a98e8b.o
  "_getType", referenced from:
      _main_ in breakout-a98e8b.o
  "_getWidthGeneric", referenced from:
      _updateScoreboard in breakout-a98e8b.o
  "_getXGeneric", referenced from:
      _main_ in breakout-a98e8b.o
      _detectCollision in breakout-a98e8b.o
  "_getYGeneric", referenced from:
      _main_ in breakout-a98e8b.o
      _detectCollision in breakout-a98e8b.o
  "_main", referenced from:
     implicit entry/start for main executable
     (maybe you meant: _main_)
  "_move", referenced from:
      _main_ in breakout-a98e8b.o
  "_newGLabel", referenced from:
      _main_ in breakout-a98e8b.o
      _initScoreboard in breakout-a98e8b.o
      _initLives in breakout-a98e8b.o
  "_newGOval", referenced from:
      _initBall in breakout-a98e8b.o
  "_newGRect", referenced from:
      _initBricks in breakout-a98e8b.o
      _initPaddle in breakout-a98e8b.o
  "_newGWindow", referenced from:
      _main_ in breakout-a98e8b.o
  "_removeGWindow", referenced from:
      _main_ in breakout-a98e8b.o
  "_setColor", referenced from:
      _initBricks in breakout-a98e8b.o
      _initPaddle in breakout-a98e8b.o
  "_setFilled", referenced from:
      _initBricks in breakout-a98e8b.o
      _initPaddle in breakout-a98e8b.o
  "_setFont", referenced from:
      _main_ in breakout-a98e8b.o
      _initScoreboard in breakout-a98e8b.o
      _initLives in breakout-a98e8b.o
  "_setLabel", referenced from:
      _updateScoreboard in breakout-a98e8b.o
      _updateLives in breakout-a98e8b.o
  "_setLocation", referenced from:
      _main_ in breakout-a98e8b.o
      _updateScoreboard in breakout-a98e8b.o
      _updateLives in breakout-a98e8b.o
  "_waitForClick", referenced from:
      _main_ in breakout-a98e8b.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: *** [breakout] Error 1

Thought this might be because SPL is 32 bit, I tried compiling for 32-bit mode by adding a -m32 option for clang, but that results in similar errors:

MacBook-Pro:pset4 luke$ clang -ggdb3 -Ispl/include -O0 -std=c99 -Wall -Werror -Wno-unused-variable -o breakout -m32 breakout.c -Lspl/lib -lcs -lm
ld: warning: ignoring file spl/lib/libcs.a, file was built for archive which is not the architecture being linked (i386): spl/lib/libcs.a
Undefined symbols for architecture i386:
  "_add", referenced from:
      _initScoreboard in breakout-007735.o
      _initBricks in breakout-007735.o
      _initBall in breakout-007735.o
      _initPaddle in breakout-007735.o
      _initLives in breakout-007735.o

It seems that SPL is compiled with some architecture that is not compatible with OS X, although I would have thought it would be standard.

Update 25 July '14

Marty Stepp responded to my email requesting C source:

The libraries are nowadays distributed as source here:

http://stanford.edu/~stepp/cppdoc/

This site also contains the latest documentation on how to use the libraries.

This links to what appears to be C++ code only. This doesn't seem to be directly compatible with C. I'm assuming there is no official C version. I'm guessing the version provided for CS50 is from another source.