Syn68k has not been actively worked on since about 1995.  A few mods
have been made here and there to keep up with changes in gcc.  Those
mods may actually interfere with compiling on older versions of gcc.
Oh well.

For a few years I've been meaning to verify that the code builds,
write a little documentation, explain a little history, maybe even set
up a mailing list for people, etc... but other things continue to take
precedence.

On an i386 Fedora 9, this version of Syn68k compiles and produces a
libsyn68k.a that works with Executor.  In a few days Fedora 11 will be
out, using gcc 4.4.  I'll try to make it so that Syn68k works on it as
well as older Fedora systems too.  I'll try to get it so the i386
version of Syn68k works on gcc 4.1, 4.2, 4.3 and 4.4.

Back in the day, Syn68k was very portable and could be run on non-x86
boxes.  I wouldn't be surprised to find that the non-x86 versions fail
to work now.  However, once the i386 version runs nicely on a variety
of gccs it may be fun for someone to make the non i386 versions run
again.

To compile syn68k on a 32-bit i386 system, try

  ./autogen.sh
  ./configure
  make
  make install

To compile syn68k on a 64-bit x86_64 system, make sure you have all
the 32-bit libraries you need (on Fedora 10 I needed to install
glibc-devel.i386 and libgcc.i386) then try this hack

  ./autogen.sh
  CC='gcc -m32' ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
  make
  make install

To compile syn68k on Mac OS X (tested under 10.5.7), you currently
have to override the cleanup script, since the stock script
(i486-cleanup.pl) will consume all of syn68k.s.

  ./autogen.sh
  CLEANUP='' ./configure
  make
  make install

To test syn68k, run test/syngentest and compare the output to
test/output/10000.  It should be the same, assuming the same block of
memory can be obtained for the test.  If you want to be more thorough,
you can use other command line options and compare the results to
other files, as described in test/output/README.

Performance nit:

The code in runtime/i486-cleanup.pl no longer gets rid of all the
cruft in the trailer (except under Mac OS X, where it gets rid of way
too much code).  It's quite possible that the code in
runtime/i486-optimize.pl doesn't do the right thing either.

My email address is still <ctm@ardi.com>, although ARDI itself is
defunct.  I get a ridiculous amount of spam and will quite possibly
not see email addressed to me.