Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tag: ppc_gencgc_all…
Fetching contributors…

Cannot retrieve contributors at this time

file 178 lines (162 sloc) 8.119 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178

The two files that SBCL needs to run, at minimum, are sbcl and sbcl.core.
They are in

sbcl is a standard executable, built by compiling and linking an
ordinary C program. It provides the runtime environment for the
running Lisp image, but it doesn't know much about high-level Lisp
stuff (like symbols and printing and objects) so it's pretty useless
by itself. sbcl.core is a dump file written in a special SBCL format
which only sbcl understands, and it contains all the high-level Lisp

In order to get a usable system, you need to run sbcl in a way that
it can find sbcl.core. There are three ways for it to find

  1. by default, in /usr/lib/sbcl/sbcl.core or /usr/local/lib/sbcl/sbcl.core
  2. by environment variable:
     $ export SBCL_HOME=/foo/bar/
     $ sbcl
  3. by command line option:
     $ sbcl --core /foo/bar/sbcl.core"
The usual, recommended approach is method #1. Method #2 is useful if
you're installing SBCL on a system in your user account, instead of
installing SBCL on an entire system. Method #3 is mostly useful for
testing or other special cases.

So: the standard installation procedure is
  1. Copy sbcl.core to /usr/lib or /usr/local/lib.
  2. Copy sbcl to /usr/bin or /usr/local/bin.
  3. Copy the contrib modules that you're using (if any) to the same place
      as sbcl.core
  4. Optionally copy sbcl.1 to /usr/man/man1 or /usr/local/man/man1.

The script does all of this for you, including compilation
of all contrib modules it can find, and installation of all those that
pass their tests. You should set the INSTALL_ROOT environment
variable to /usr or /usr/local as appropriate before starting e.g.

   # INSTALL_ROOT=/usr/local sh


   $ INSTALL_ROOT=/home/me/sbcl sh


This software has been built successfully on these systems:
cpu = x86 (Intel 386 or higher, or compatibles like the AMD K6)
os = Debian GNU/Linux 2.1 with libc >= 2.1
host lisp = CMU CL 2.4.17
host lisp = SBCL itself
host lisp = CLISP CVS as of end of April
os = RedHat Linux 6.2
host lisp = SBCL itself
os = FreeBSD 3.4 or 4.0
host lisp = CMU CL
host lisp = SBCL itself
os = OpenBSD 2.6, 2.7, 2.8, 2.9, and 3.0
host lisp = SBCL itself
cpu = alpha
os = Debian GNU/Linux 2.2 with libc >= 2.1
host lisp = SBCL itself
os = Tru64 5.1
host lisp = SBCL itself
cpu = sparc
os = Debian GNU/Linux 2.2 with libc >= 2.2
host lisp = SBCL itself
os = Solaris 8
host lisp = SBCL itself
cpu = powerpc
os = Debian GNU/Linux 2.2 with libc >= 2.1
host lisp = OpenMCL 0.12
host lisp = SBCL itself
os = MacOS X.2
host lisp = OpenMCL 0.13.6
host lisp = SBCL itself
cpu = mips and mipsel
os = Debian GNU/Linux 3.0
host lisp = SBCL itself

Reports of other systems that it works on (or doesn't work on, for
that matter), or help in making it run on more systems, would be

SBCL, like CMU CL, overcommits memory. That is, it
asks the OS for more virtual memory address space than
it actually intends to use, and the OS is expected to
optimistically give it this address space even if the OS
doesn't have enough RAM+swap to back it up. This works
fine as long as SBCL's memory usage pattern is sparse
enough that the OS can actually implement the requested
VM usage. Unfortunately, if the OS runs out of RAM+swap to
implement the requested VM usage, things get bad. On many
systems, including the Linux 2.2.13 kernel that I used for
development of SBCL up to version 0.6.0, the kernel kills
processes more-or-less randomly when it runs out of
resources. You may think your Linux box is very stable, but
it is unlikely to be stable if this happens.:-| So be sure
to have enough memory available when you build the system.
(This can be considered a bug in SBCL, or a bug in the
Unix overcommitment-of-memory architecture, or both. It's
not clear what the best fix is. On the SBCL side, Peter Van
Eynde has a lazy-allocation patch for CMU CL that lets
it run without overcommitting memory, and that could be
ported to SBCL, but unfortunately that might introduce
new issues, e.g. alien programs allocating memory in the
address space that SBCL thinks of as its own, and later
getting trashed when SBCL lazily allocates the memory.
On the OS side, there might be some way to address the
problem with quotas, I don't know.)

To build the system binaries:
  0. If you want to be on the bleeding edge, you can update your
     sources to the latest development snapshot (or any previous
     development snapshot, for that matter) by using anonymous CVS
     to SourceForge. (This is not recommended if you're just using SBCL
     as a tool for other work, but if you're interested in working on
     SBCL itself, it's a good idea.) Follow the "CVS Repository" link on
     <> for instructions.
  1. Make sure that you have enough RAM+swap to build SBCL, as
     per the CAUTION note above. (As of version 0.6.0, the most
     memory-intensive operation in is the second call to
     GENESIS, which makes the Lisp image grow to around 128 Mb RAM+swap.
  2. If the GNU make command is not available under the names "gmake"
     or "make", then define the environment variable GNUMAKE to a name
     where it can be found.
  3. If you like, you can tweak the *FEATURES* set for the resulting
     Lisp system, enabling or disabling features like documentation
     strings or extra debugging code. The preferred way to do this is
     by creating a file "customize-target-features.lisp", containing
     a lambda expression which is applied to the default *FEATURES*
     set and which returns the new *FEATURES* set, e.g.
     (This is the preferred way because it lets local changes interact
     cleanly with CVS changes to the main, global source tree.)
  4. Run "sh" in the same directory where you unpacked the
     tarball. If you don't already have a SBCL binary installed
     as "sbcl" in your path, you'll need to tell what Lisp
     system to use as the cross-compilation host. (To use CMU CL
     as the cross-compilation host, run "sh 'lisp -batch'",
     assuming CMU CL has been installed under its default name "lisp".)
  5. Wait. This can be a slow process. On my test machines, the
     wall clock time for a build of sbcl-0.6.7 was approximately
       1.5 hours on a 450MHz K6/3 with 248Mb RAM, running RH Linux 6.2;
       4 hours on a 200MHz Pentium (P54C) with 64Mb RAM, running FreeBSD 4.0;
       13 hours on a 133MHz Pentium (P54C) with 48Mb RAM, running OpenBSD 2.6.
     Around the 48Mb mark, the build process is starved for RAM:
     on my 48Mb OpenBSD machine with nothing else running, it
     spent about 2/3 of its wall clock time swapping.

Now you should have the same src/runtime/sbcl and output/sbcl.core
files that come with the binary distribution, and you can install
them as in the "IF YOU HAVE A BINARY DISTRIBUTION" instructions (above).

To convert the DocBook version of the system documentation (files
ending in .sgml) to more-readable form (HTML or text):
  DocBook is an abstract markup system based on SGML. It's intended
  to be automatically translated to other formats. Tools to do this
  exist on the web, and are becoming increasingly easy to find as
  more free software projects move their documentation to DocBook.
  Any one of these systems should work with the SBCL documentation.
  If you'd like to have the documentation produced in the same
  format as appears in the binary distribution, and you have
  the jade binary and Norman Walsh's modular DSSSL stylesheets
  installed, you can try the doc/ script. Otherwise,
  your formatted copy of the SBCL documentation should have the
  same content as in the binary distribution, but details of
  presentation will probably vary.
Something went wrong with that request. Please try again.