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

Syn68k doesn't currently compile under Mac OS X (tested under 10.5.7)
due to the use of leading underscores in the symbol table (this is
easily fixed) and and due to their version of ld not knowing that
-2147483648 is a valid 32-bit relative offset (the error message is
ld: rel32 out of range in _code_start_24 in _code_start_24).  That's a
little harder to fix.

To test syn68k, run test/syngentest and compare the output to
test/output/10000.  It should be the same.  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.  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.