I am running and building Clisp on NetBSD ever since.
I just checked Clisp-19940901 on FreeBSD-2.1-951005-SNAP, using
gcc-2.7.0 and it just works when sys_errlist is handled. There are
many places where FreeBSD (and NetBSD) chose to change datatypes, so
warnings about signed/unsigned operations are common. The testsuite
failes with floating point underflow, which may be related to
FreeBSD's barfink on FP exceptions. I am going to try a more rescent
release of Clisp.
Everyone having problems with Lisp/Scheme implementations on NetBSD or
FreeBSD should contact me with(!) the necessary information. With the
excetion of Rscheme, I think I have every recent implementation
running on at least NetBSD/i386. That doesn't mean I stress-tested
them, a leaking GC could slip through. I run implementation-provided
test suites, though.
Remember that NetBSD/i386 has a very descent Linux emulator (which,
for example, runs MIT-Scheme) and FreeBSD is catching up. If you
really can't compile on *BSD, try a Linux binary.
One possible reason for breaking binaries in the build process of
image-based programming language implementations are shell limits for
maximum datasize or stacksize of processes. Try `limit` or `ulimit` to
find out. Unfortunatly, in some *BSD releases, some shells has default
values to limit resources instead of unlimiting them until the user
wants to limit. bash(1) is an example.
And remove sys_errlist definitions or change them to 'const'.
Happy Hacking
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de> - BSD User Group Hamburg, Germany
"As far as I'm concerned, if something is so complicated that you can't ex-"
"plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin