| 
 | 
 | 
  | 
  
 Platforms: what does it run on?
    |  
 
 The current release of CMUCL should work on the following combinations
    of operating system and architecture:
 
-  Linux/x86 
 
-  The 19f release should work on any i586 or better processor.  If
     the processor supports SSE2, CMUCL will automatically detect that
     and use SSE2.  Otherwise the legacy x87 support will be used.
     
The 19e release binaries should work on any i586 or better processor.
     The binaries are compiled against version 2.2 of the GNU C Library
     (glibc2.2), but also work with glibc2.3. The runtime support for the
     CMUCL Motif interface is dynamically linked, so you will need the
     Motif or Lesstif libraries (preferably version 2) installed on your
     system to use it. The binaries should run with any Linux kernel after
     2.0 (but beware early kernels in the 2.4 series, which had poor
     virtual memory characteristics).
       There are problems running CMUCL on certain kernels that are built
     with address-space randomization techniques, such as certain Fedora
     kernels. If you run into problems, please use a vanilla kernel.
       There are known problems running CMUCL on 2.4 kernels using certain
     configurations of the HIGHMEM support (this option allows larger
     process address spaces, and certain distributions ship kernels with
     these patches enabled). The CONFIG_64GB and
     CONFIG_1GB options work fine.
       CMUCL is known not to run under libsafe, whose system call
     interposition mechanism interferes with the foreign function
     interface. CMUCL does not run on kernels with "hardening"
     patches such as grsecurity, since their all-the-world-is-C
     assumptions are too strong.
  
-  Darwin/x86 
 
-  
The 20a release binaries were built on MacOSX 10.5 (Leopard) and
     probably require 10.5 or later. 
     The 19f release binaries should work on any processor supported by
     MacOS X (x86). They require 10.4 (Tiger) or later. 
 
-  FreeBSD/i386 and amd64 
 
-  The 19e release binaries have been built on the i386
     architecture, on which they will, of course, work; they will also
     work, with proper i386 compatibility library installed, on the
     amd64 architecture.  New binaries can't be at this point built on
     the amd64 architecture, though -- i386 binaries should be used
     there.
     
 Notice that the architecture in question is the OS
     architecture ("target"), not the processor's one -- FreeBSD/i386
     running on an amd64 processor is good for all CMUCL purposes,
     including building new binaries.
       An appropriately chosen distibution
     (e.g. `cmucl-19e-x86-freebsd7.0.*', for FreeBSD 7.0) should work
     on FreeBSD 6.3, 7.0 and 8.0.  Using a "later" FreeBSD
     distribution on an "earlier" FreeBSD release
     (e.g. `cmucl-19e-x86-freebsd7.0.*' on FreeBSD 6.3) is either not
     possible or not tested.  Using an "earlier" FreeBSD distribution
     on a "later" FreeBSD release should be possible with appropriate
     compatibility libraries installed but has not be tested and is
     advised against --- use the binaries built on the OS release they
     are going to run on.
       Legacy FreeBSD releases (earlier than 6.3) have not been
     tested as runtime platforms and will be not supported, although
     the 6.3 distribution may run on them.
       FreeBSD 6 will be not supported after CMUCL release 19e.
  
-  Solaris/SPARC 
 
-  
The 19f binaries should work with Solaris 8 or later (also known
     as Solaris 2.8). They require an UltraSPARC processor. If you
     have an ancient SPARC machine, you can get the non-v9 version of
     the 18e release. If you have an UltraSPARC the command
     uname -m will say sun4u, if you have an
     older machine such as a SparcStation it will probably say
     sun4m.  
     
     
     Note that starting with the 2010-02 snapshot, Solaris 8 builds
     are being dropped in favor of Solaris 10 builds.  The Solaris 10
     builds will not run on Solaris 8, but Solaris 8 builds will run
     just fine on Solaris 10.  However, Solaris 8 builds may be
     available.  
 
-  NetBSD/x86 
 
-  The 19c release binaries should work on any i586 or better processor.
     The 19c binaries should work with NetBSD releases xx and yy. 
 
 
 The following platforms are not supported by the current CMUCL release,
    but were supported by previous releases:
 
-  Darwin/ppc 
 
-  The 19f release binaries work with MacOS X version 10.4.  For
older versions of MacOS X, use the 19c binaries.  No developer has
access to a ppc running MacOS X anymore.
 
-  OpenBSD/x86 
 
-  There are currently no 19c binaries for OpenBSD (it seems that address
     space randomization techniques introduced with recent versions of
     OpenBSD interfere with CMUCL's memory management). The 18e release
     binaries should work on any i486 or better processor. The 18e binaries
     were build on OpenBSD 3.1. 
 
-  Alpha/Linux 
 
-  There are no 19c binaries for Alpha. The 18e binaries are known to
     work on ev56 and ev6 machines, running Linux 2.4.x. 
 
-  IRIX/MIPS 
 
-  There are no 19c binaries for IRIX. The 18e release binaries are known
     to work with Irix 6.2, and should work on any later version. They use
     the o32 ABI. 
 
-  HPUX/HPPA 
 
-  this port has not been maintained for quite a while, so
     you'll have to go back to the 18a release to find binaries for this
     platform. 
 
 
 The SBCL implementation (a fork
    from CMUCL) runs on some platforms that CMUCL doesn't currently
    support, such as Linux/SPARC, Linux/PowerPC, Linux/Alpha -- check their
    web site for current status.  
Platform-specific build options
 The builds for x86, sparc, and ppc platforms include a
generational conservative garbage collector (this can be tested for
through the presence of the :gencgc feature). The other
architectures use a stop-and-copy garbage collector.  
 The x86 builds also include basic multiprocessing support (this can be
tested for through the presence of the :mp feature). The
implementation is based on stack groups, ie user-level threads, and not on
kernel threads. The interface is very similar to the CLIM-SYS
specification.  
 |