Please be sure to run a kernel with these fixes. Kernel versions 2.6.37 or and later should include them.

Linux/PPC

On the PPC, there are addressing modes that make it easy to deal with 16-bit
constants and 16-bit absolute addresses. CCL exploits this: things
like NIL and T are 16-bit constants (and the addresses of things
that are mapped into low memory); conditional calls to runtime
support routines can use "branch absolute" instructions to call
those routines (which are also mapped into the low 16 bits of
the address space). Apple uses a similar scheme to reference
critical library routines in Mac OS X (since the addressing mode
generally involved signed 16-bit addresses, Apple's scheme uses
addresses in the high 16 bits of the address space). That sort
of thing is what the addressing modes are for, after all.

The Linux kernel provides a feature that can prevent a process from
mapping addresses below a certain base address. The idea, apparently, is that
this will prevent exploitation of undiscovered null pointer dereference
bugs in the kernel.

The parameter in question is called mmap_min_addr; one can cat the file
/proc/sys/vm/mmap_min_addr to see what the current setting is.

Some recent Linux distributions (including Fedora 9 and Ubuntu 8) ship with
this value set to 65536. This has the effect of preventing processes from accessing
the low 64K of their address spaces. Whether this makes sense or not on other
architectures is debatable; on the PPC, it means that applications that want to exploit 16-bit
PPC addressing are prohibited from doing so.
We don't know if anyone involved in this decision thought about this issue
or what they concluded if so. It's a little hard to believe
that much thought went into that decision.

Fortunately, there are a few workarounds.

Processes running as root are not subject to the restriction. However, it's not
reasonable to require rootly powers just to run CCL.

The value of mmap_min_addr can be changed by writing a new value
to the file /proc/sys/vm/mmap_min_addr like so:

# echo 4096 >/proc/sys/vm/mmap_min_addr

This will persist only until the system is rebooted.

It should be possible to make a permanent fix by adding the line

vm.mmap_min_addr=4096

to the file /etc/sysctl.conf. (This change will take effect on
the next and subsequent reboots.)

The 4K value mentioned above will protect against certain (yet-to-be-discovered) NULL pointer deference bugs in
the kernel, but will still allow applications to use low-memory addresses.

On some newer systems (Ubuntu 8.10, for instance, at least in the PS3 distribution), the 4K value doesn't work, although

# echo 0 >/proc/sys/vm/mmap_min_addr

will permit the lisp to run. (Setting this value to 0 doesn't necessarily make your system insecure.
It might, however, make it possible or easier to exploit yet-to-be-discovered bugs in the Linux kernel.)

On the x86 platform, there's no architectural advantage to using 16-bit
addresses (when it's even possible to do so). Version 1.1 of
CCL/OpenMCL happened to use very similar/very low addresses
(there was no reason not to); 1.2 and later use addresses
above 64K (mostly because Windows restricts access to the low
64K for other reasons.)

It might be possible to rearchitect PPC CCL not to
exploit this architectural feature, but the thought of
doing so is not particularly attractive.

FreeBSD (i386,amd64)

The distributed versions of Clozure CL are built on a FreeBSD 6.4 system; they should run unmodified on any 6.x system.
(In general, the 64-bit version requires a 64-bit ("amd64") FreeBSD release; the 32-bit version of CCL should run on a 32-bit FreeBSD release or on a 64-bit release if the "lib32" 32-bit libraries are installed.)

FreeBSD changes library versions on major releases and executable files refer to the libraries that they depend on via versioned names, so the distributed CCL kernel (built on a 6.x system) won't run on a 7.x FreeBSD system (because the 6.x versions of the libraries it depends on aren't installed.) There are two ways to work around this:

Install the "compat6x" package, which provides the 6.x libraries on a 7.x system. This can be done via the FreeBSD ports system:

$ cd /usr/ports/misc/compat6x
$ sudo make install

Build the kernel yourself on the 7.x system

$ cd ccl/lisp-kernel/freebsdx8632 # or freebsdx8664
$ make

FreeBSD doesn't provide the same level of support for multi-arch development (e.g., compiling 32-bit C code on 64-bit systems and vice versa) that Darwin, most Linux distributions, and Solaris offer; it's not generally possible to compile a 32-bit FreeBSD kernel on a 64-bit FreeBSD system. And vice versa.

It should be possible to run a 32-bit FreeBSD CCL on a 64-bit FreeBSD system and it generally is. Unfortunately, CCL triggers a bug that was introduced in the 7.1 release version of the 64-bit FreeBSD kernel (7.0 and 6.x are not affected.) See http://www.freebsd.org/cgi/query-pr.cgi?pr=130526
if you're interested in the gory details; the source patch in the responses to the bug report seems to work, so recompiling the 64-bit FreeBSD 7.1 kernel should enable 32-bit CCL to run on 64-bit FreeBSD 7.1. A bug that prevented 32-bit CCL from running on FreeBSD 7.1/amd64 systems has been fixed in FreeBSD 7.2

Solaris (x86)

The GNU m4 included with Open Solaris has bugs that
prevent it from being usable for the build of the lisp kernel.
It's probably easiest to retrieve the latest GNU m4 sources from
someplace (http://ftp.gnu.org/gnu/m4/ is one possibility), and build them locally.
The lisp kernel makefiles expect a working GNU m4 to be installed as /usr/local/bin/m4,
so it will be necessary to edit ccl/lisp-kernel/solarisx{86,64}/Makefile if you install the
m4 binary elsewhere.