From: Nikodemus S. <tsi...@cc...> - 2004-05-27 11:50:24
|
Appended is a heavily edited version of the INSTALL file. Given the difficulty of editing prose, I'm posting it here for flamage... ;-) Suboptimalities still include eg. non-addressal of installing documentation. Cheers, -- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time." INSTALLING SBCL CONTENTS 1. BINARY DISTRIBUTION 1.1. Quick start 1.2. Finding core 1.3. Anatomy of SBCL 2. SOURCE DISTRIBUTION 2.1. CAUTION 2.2. Quick start 2.3. Customizing SBCL 2.4. Troubleshooting 2.5. Tracking SBCL sources 2.6. Known good platforms 1. BINARY DISTRIBUTION 1.1. Quick start: The following command installs SBCL under the "/usr/local" directory: # INSTALL_ROOT=/usr/local sh install.sh You can also install SBCL as a user, under your home directory: $ INSTALL_ROOT=/home/me sh install.sh In other words, "install.sh" installs SBCL is under the directory named by the environment variable "INSTALL_ROOT". If you install SBCL from binary distribution in other location then "/usr/local", see section 1.2, "Finding core". 1.2. Finding core The SBCL runtime needs to be able to find the "sbcl.core" associated with it. This can happen in three ways: 1. By default, in a location configured when the system was built. For binary distributions this is "/usr/local/lib/sbcl/sbcl.core". 2. By environment variable, as "sbcl.core" in the directory named by the environment variable "SBCL_HOME". Example: $ export SBCL_HOME=/foo/bar/lib/sbcl $ sbcl If your "INSTALL_ROOT" was FOO, then your "SBCL_HOME" is "FOO/lib/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 a non-standard location (e.g. in your user account), instead of installing SBCL on an entire system. Method #3 is mostly useful for testing or other special cases. 1.3. Anatomy of SBCL The two files that SBCL needs to run, at minimum, are: src/runtime/sbcl output/sbcl.core In addition, there are a number of modules that extend the basic sbcl functionality, in contrib/ The "src/runtime/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. The "output/sbcl.core" is a dump file written in a special SBCL format which only sbcl understands, and it contains all the high-level Lisp stuff. 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 install.sh 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 install.sh, as indicated in the section 1.0 "Quick Start". 2. SOURCE DISTRIBUTION 2.1. CAUTION 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. 2.2. Quick start You need a working toolchain and a Common Lisp system to build SBCL. SBCL is known to build on CMUCL, CLISP (recent versions of CLISP only), OpenMCL, and SBCL itself. 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 during build is the second call to GENESIS, which makes the Lisp image grow to around 128 Mb RAM+swap. To build SBCL using an already installed SBCL: $ sh make.sh If you don't already have a SBCL binary installed as "sbcl" in your path, you'll need to tell make.sh what Lisp system to use as the cross-compilation host. For example, To use CMU CL as the cross-compilation host: $ sh make.sh 'lisp -batch' assuming CMU CL has been installed under its default name "lisp". Building SBCL can be a slow process, depending on your computer. Some typical build times (wall-clock time): 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. To run the regression tests: $ cd tests && sh run-tests.sh To build documentation: $ cd doc/manual && make This builds the Info, HTML and PDF documentation from the TexInfo sources. The manual includes documentation string from the build SBCL, but if SBCL itself has not been yet built, but one if found installed documentation strings from the installed version are used. 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 described in the section 1. "BINARY DISTRIBUTION". 2.3. Customizing SBCL You can tweak the *FEATURES* set for the resulting Lisp system, enabling or disabling features like documentation strings, threads, 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. (lambda (features) (flet ((enable (x) (pushnew x features)) (disable (x) (setf features (remove x features)))) ;; Threading support, available on x86 Linux only. (enable :sb-thread) ;; Slightly smaller core (disable :sb-doc))) This is the preferred way because it lets local changes interact cleanly with CVS changes to the main, global source tree. Catalog of available features and their meaning can be found in "base-target-features.lisp-expr". 2.4. Troubleshooting "GNU Make not found" If the GNU make command is not available under the names "make", "gmake", or "gnumake", then define the environment variable GNUMAKE to a name where it can be found. Other * Check that the host lisp you're building with is known to work as an SBCL build host, and the your OS is supported. * Some GCC versions are known to have bugs that affect SBCL compilation: if the error you're encountering seems related to files under "src/runtime", down- or upgrading GCC may help. * Ask for help on the mailing list <sbc...@so...>. 2.5. Tracking SBCL sources 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 <http://sourceforge.net/projects/sbcl> for instructions. 2.6. Known good platforms 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 appreciated. |
From: Nikodemus S. <tsi...@cc...> - 2004-05-27 12:30:27
|
On Thu, 27 May 2004, Christophe Rhodes wrote: > ENOGRAMMAR :-) Oops. > > The script install.sh 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 > > Does it really? I thought it just copied stuff where it found a > test-passed file. Heh. I just copy & pasted that from the original, but you're right. > The e-mail address is wrong. But that's OK, because ideally e-mail > addresses don't appear in source code, both for maintenance reasons > and also because spam crawlers love viewcvs. Ok. Fixed version below for further abuse. (Includes one additional change of wording to avoid the first person form.) Cheers, -- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time." INSTALLING SBCL CONTENTS 1. BINARY DISTRIBUTION 1.1. Quick start 1.2. Finding core 1.3. Anatomy of SBCL 2. SOURCE DISTRIBUTION 2.1. CAUTION 2.2. Quick start 2.3. Customizing SBCL 2.4. Troubleshooting 2.5. Tracking SBCL sources 2.6. Known good platforms 1. BINARY DISTRIBUTION 1.1. Quick start: The following command installs SBCL under the "/usr/local" directory: # INSTALL_ROOT=/usr/local sh install.sh You can also install SBCL as a user, under your home directory: $ INSTALL_ROOT=/home/me sh install.sh In other words, "install.sh" installs SBCL is under the directory named by the environment variable "INSTALL_ROOT". If you install SBCL from binary distribution in other location then "/usr/local", see section 1.2, "Finding core". 1.2. Finding core The SBCL runtime needs to be able to find the "sbcl.core" associated with it. This can happen in three ways: 1. By default, in a location configured when the system was built. For binary distributions this is "/usr/local/lib/sbcl/sbcl.core". 2. By environment variable, as "sbcl.core" in the directory named by the environment variable "SBCL_HOME". Example: $ export SBCL_HOME=/foo/bar/lib/sbcl $ sbcl If your "INSTALL_ROOT" was FOO, then your "SBCL_HOME" is "FOO/lib/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 a non-standard location (e.g. in your user account), instead of installing SBCL on an entire system. Method #3 is mostly useful for testing or other special cases. 1.3. Anatomy of SBCL The two files that SBCL needs to run, at minimum, are: src/runtime/sbcl output/sbcl.core In addition, there are a number of modules that extend the basic sbcl functionality, in contrib/ The "src/runtime/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. The "output/sbcl.core" is a dump file written in a special SBCL format which only sbcl understands, and it contains all the high-level Lisp stuff. 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 install.sh 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 install.sh, as indicated in the section 1.0 "Quick Start". 2. SOURCE DISTRIBUTION 2.1. CAUTION 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. 2.2. Quick start You need a working toolchain and a Common Lisp system to build SBCL. SBCL is known to build on CMUCL, CLISP (recent versions of CLISP only), OpenMCL, and SBCL itself. 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 during build is the second call to GENESIS, which makes the Lisp image grow to around 128 Mb RAM+swap. To build SBCL using an already installed SBCL: $ sh make.sh If you don't already have a SBCL binary installed as "sbcl" in your path, you'll need to tell make.sh what Lisp system to use as the cross-compilation host. For example, To use CMU CL as the cross-compilation host: $ sh make.sh 'lisp -batch' assuming CMU CL has been installed under its default name "lisp". Building SBCL can be a slow process, depending on your computer. Some typical build times (wall-clock time): 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. To run the regression tests: $ cd tests && sh run-tests.sh To build documentation: $ cd doc/manual && make This builds the Info, HTML and PDF documentation from the TexInfo sources. The manual includes documentation string from the build SBCL, but if SBCL itself has not been yet built, but one if found installed documentation strings from the installed version are used. 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 described in the section 1. "BINARY DISTRIBUTION". 2.3. Customizing SBCL You can tweak the *FEATURES* set for the resulting Lisp system, enabling or disabling features like documentation strings, threads, 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. (lambda (features) (flet ((enable (x) (pushnew x features)) (disable (x) (setf features (remove x features)))) ;; Threading support, available on x86 Linux only. (enable :sb-thread) ;; Slightly smaller core (disable :sb-doc))) This is the preferred way because it lets local changes interact cleanly with CVS changes to the main, global source tree. Catalog of available features and their meaning can be found in "base-target-features.lisp-expr". 2.4. Troubleshooting "GNU Make not found" If the GNU make command is not available under the names "make", "gmake", or "gnumake", then define the environment variable GNUMAKE to a name where it can be found. Other * Check that the host lisp you're building with is known to work as an SBCL build host, and the your OS is supported. * Some GCC versions are known to have bugs that affect SBCL compilation: if the error you're encountering seems related to files under "src/runtime", down- or upgrading GCC may help. * Ask for help on the mailing list <sbc...@so...>. 2.5. Tracking SBCL sources 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 <http://sourceforge.net/projects/sbcl> for instructions. 2.6. Known good platforms 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 appreciated. |
From: Nikodemus S. <tsi...@cc...> - 2004-05-27 12:32:57
|
On Thu, 27 May 2004, Nikodemus Siivola wrote: > Fixed version below for further abuse. (Includes one additional change of > wording to avoid the first person form.) Agah. Wrong version. Sorry for the spam. Cheers, -- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time." INSTALLING SBCL CONTENTS 1. BINARY DISTRIBUTION 1.1. Quick start 1.2. Finding core 1.3. Anatomy of SBCL 2. SOURCE DISTRIBUTION 2.1. CAUTION 2.2. Quick start 2.3. Customizing SBCL 2.4. Troubleshooting 2.5. Tracking SBCL sources 2.6. Known good platforms 1. BINARY DISTRIBUTION 1.1. Quick start: The following command installs SBCL under the "/usr/local" directory: # INSTALL_ROOT=/usr/local sh install.sh You can also install SBCL as a user, under your home directory: $ INSTALL_ROOT=/home/me sh install.sh In other words, "install.sh" installs SBCL under the directory named by the environment variable "INSTALL_ROOT". If you install SBCL from binary distribution in other location then "/usr/local", see section 1.2, "Finding core". 1.2. Finding core The SBCL runtime needs to be able to find the "sbcl.core" associated with it. This can happen in three ways: 1. By default, in a location configured when the system was built. For binary distributions this is "/usr/local/lib/sbcl/sbcl.core". 2. By environment variable, as "sbcl.core" in the directory named by the environment variable "SBCL_HOME". Example: $ export SBCL_HOME=/foo/bar/lib/sbcl $ sbcl If your "INSTALL_ROOT" was FOO, then your "SBCL_HOME" is "FOO/lib/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 a non-standard location (e.g. in your user account), instead of installing SBCL on an entire system. Method #3 is mostly useful for testing or other special cases. 1.3. Anatomy of SBCL The two files that SBCL needs to run, at minimum, are: src/runtime/sbcl output/sbcl.core In addition, there are a number of modules that extend the basic sbcl functionality, in contrib/ The "src/runtime/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. The "output/sbcl.core" is a dump file written in a special SBCL format which only sbcl understands, and it contains all the high-level Lisp stuff. 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 install.sh does all of this for you. You should set the INSTALL_ROOT environment variable to /usr or /usr/local as appropriate before starting install.sh, as indicated in the section 1.0 "Quick Start". 2. SOURCE DISTRIBUTION 2.1. CAUTION 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 was 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. 2.2. Quick start You need a working toolchain and a Common Lisp system to build SBCL. SBCL is known to build on CMUCL, CLISP (recent versions of CLISP only), OpenMCL, and SBCL itself. 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 during build is the second call to GENESIS, which makes the Lisp image grow to around 128 Mb RAM+swap. To build SBCL using an already installed SBCL: $ sh make.sh If you don't already have a SBCL binary installed as "sbcl" in your path, you'll need to tell make.sh what Lisp system to use as the cross-compilation host. For example, To use CMU CL as the cross-compilation host: $ sh make.sh 'lisp -batch' assuming CMU CL has been installed under its default name "lisp". Building SBCL can be a slow process, depending on your computer. Some typical build times (wall-clock time): 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. To run the regression tests: $ cd tests && sh run-tests.sh To build documentation: $ cd doc/manual && make This builds the Info, HTML and PDF documentation from the TexInfo sources. The manual includes documentation string from the build SBCL, but if SBCL itself has not been yet built, but one if found installed documentation strings from the installed version are used. 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 described in the section 1. "BINARY DISTRIBUTION". 2.3. Customizing SBCL You can tweak the *FEATURES* set for the resulting Lisp system, enabling or disabling features like documentation strings, threads, 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. (lambda (features) (flet ((enable (x) (pushnew x features)) (disable (x) (setf features (remove x features)))) ;; Threading support, available on x86 Linux only. (enable :sb-thread) ;; Slightly smaller core (disable :sb-doc))) This is the preferred way because it lets local changes interact cleanly with CVS changes to the main, global source tree. Catalog of available features and their meaning can be found in "base-target-features.lisp-expr". 2.4. Troubleshooting "GNU Make not found" If the GNU make command is not available under the names "make", "gmake", or "gnumake", then define the environment variable GNUMAKE to a name where it can be found. Other * Check that the host lisp you're building with is known to work as an SBCL build host, and the your OS is supported. * Some GCC versions are known to have bugs that affect SBCL compilation: if the error you're encountering seems related to files under "src/runtime", down- or upgrading GCC may help. * Ask for help on the mailing lists referenced from <http://www.sbcl.org/>. 2.5. Tracking SBCL sources 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 <http://sourceforge.net/projects/sbcl> for instructions. 2.6. Known good platforms 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 appreciated. |
From: David S. <da...@da...> - 2004-05-27 21:17:42
|
Nikodemus Siivola <tsi...@cc...> writes: > 2.6. Known good platforms > > cpu = powerpc > os = MacOS X.2 > host lisp = OpenMCL 0.13.6 > host lisp = SBCL itself I wonder if it should be mentioned that OpenMCL 0.14.1-p1 also works. Or are you just going with the earliest known version even if a later version may break something? (unlikely in this case, but you never know). -- An ideal world is left as an excercise to the reader. --- Paul Graham, On Lisp 8.1 |
From: Daniel B. <da...@te...> - 2004-05-27 14:22:06
|
Nikodemus Siivola <tsi...@cc...> writes: > Appended is a heavily edited version of the INSTALL file. Given the > difficulty of editing prose, I'm posting it here for flamage... ;-) lit crit, yay > 1.2. Finding core "1.2. Finding ancillary files" > The SBCL runtime needs to be able to find the "sbcl.core" associated > with it. "The SBCL runtime needs to be able to find ancillary files associated with it: the "sbcl.core" file, and the contrib modules." > So, the standard installation procedure is: ... to use the install.sh script, because it seems to be updated more often when things change than the instructions for installing by hand do. If you must list the steps to do it by hand as well, make it clear that it's the second-best choice (and, probably, advise the reader to look at install.sh for up-to-date information) > 2. SOURCE DISTRIBUTION > > 2.1. CAUTION Do we really need all of this memory overcommit tutorial in an installation document? > 2.2. Quick start > > You need a working toolchain and a Common Lisp system to build SBCL. > SBCL is known to build on CMUCL, CLISP (recent versions of CLISP > only), OpenMCL, and SBCL itself. although we don't always test every release with every possible host compiler. You're most likely to get a clean build with SBCL itself as host, otherwise OpenMCL on a PPC and CMUCL elsewhere. > * Ask for help on the mailing list <sbc...@so...>. Should we turn this into a URL to foil spambots in case INSTALL ends up on a web site? For the malefit of any such bots reading this message on geocrawler of gmane, I have inentionally not corrected the address ;-) -dan -- "please make sure that the person is your friend before you confirm" |
From: Julian S. <der...@we...> - 2004-06-01 21:42:09
|
Nikodemus Siivola <tsi...@cc...> writes: > 2.6. Known good platforms > > 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 Do we intentionally list archaic OS versions here? Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming |
From: Nikodemus S. <tsi...@cc...> - 2004-06-01 22:47:22
|
On Tue, 1 Jun 2004, Julian Stecklina wrote: > Do we intentionally list archaic OS versions here? Not anymore. ;-) Well, Linux 2.2 is probably archaic, and still listed even in the new version. Cheers, -- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time." |
From: Julian S. <der...@we...> - 2004-06-02 00:12:31
|
Nikodemus Siivola <tsi...@cc...> writes: > On Tue, 1 Jun 2004, Julian Stecklina wrote: > >> Do we intentionally list archaic OS versions here? > > Not anymore. ;-) Well, Linux 2.2 is probably archaic, and still listed > even in the new version. Well, FreeBSD 4.0 is more then 4 years old (I am currently using 5.2-CURRENT), OpenBSD is way past 3.0, too. :) Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming |
From: Julian S. <der...@we...> - 2004-06-02 00:18:20
|
Julian Stecklina <der...@we...> writes: > Nikodemus Siivola <tsi...@cc...> writes: > >> On Tue, 1 Jun 2004, Julian Stecklina wrote: >> >>> Do we intentionally list archaic OS versions here? >> >> Not anymore. ;-) Well, Linux 2.2 is probably archaic, and still listed >> even in the new version. > > Well, FreeBSD 4.0 is more then 4 years old (I am currently using > 5.2-CURRENT), OpenBSD is way past 3.0, too. :) Sorry for the noise, I missed the last INSTALL version. Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming |
From: Nikodemus S. <tsi...@cc...> - 2004-06-02 00:38:39
|
On Wed, 2 Jun 2004, Julian Stecklina wrote: > Well, FreeBSD 4.0 is more then 4 years old (I am currently using > 5.2-CURRENT), OpenBSD is way past 3.0, too. :) For reference, here's what the current INSTALL says: x86 PPC Alpha Sparc HPPA MIPS MIPSel Linux 2.2, 2.4, 2.6 X X X X X X X FreeBSD X OpenBSD 3.4, 3.5 X NetBSD X Solaris X Tru64 X Darwin (Mac OS X) X Nothing more archaic then Linux 2.2 left. ;-) Waitasecond... SBCL runs on OpenBSD/x86 not PPC, right? Ooops. Gotta fix that. On a related note, version numbers for FreeBSD and NetBSD would probably be in order. Cheers, -- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time." |
From: Julian S. <der...@we...> - 2004-06-02 11:47:33
|
Nikodemus Siivola <tsi...@cc...> writes: > For reference, here's what the current INSTALL says: > > x86 PPC Alpha Sparc HPPA MIPS MIPSel > Linux 2.2, 2.4, 2.6 X X X X X X X > FreeBSD X > OpenBSD 3.4, 3.5 X > NetBSD X > Solaris X > Tru64 X > Darwin (Mac OS X) X > On a related note, version numbers for FreeBSD and NetBSD would > probably be in order. Current releases of FreeBSD on x86 should do fine: 4.9, 4.10 or 5.2.1. I do not know whether SBCL works on Sparc or Alpha, though. Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming |
From: Alexey D. <ade...@co...> - 2004-06-02 16:50:36
|
Hello, Nikodemus Siivola <tsi...@cc...> writes: > For reference, here's what the current INSTALL says: > > x86 PPC Alpha Sparc HPPA MIPS MIPSel > Linux 2.2, 2.4, 2.6 X X X X X X X I tried to run recent SBCL under Linux 2.2.14 and .20 with GLibC 2.1.3, but it caused segmentation faults during huge consing (e.g. during compiling). The same SBCL works fine under 2.4. I've found a patch related to SIGSEGV handling: --- /mnt/cdrom/linux-os.c Wed May 12 17:51:00 2004 +++ /mnt/hd2/lesha/sbcl/src/runtime/linux-os.c Thu Apr 8 06:23:01 2004 @@ -222,7 +222,7 @@ void sigsegv_handler(int signal, siginfo_t *info, void* void_context) { os_context_t *context = arch_os_get_context(&void_context); - void* fault_addr = (void*)context->uc_mcontext.cr2; + void* fault_addr = (void*)info->si_addr; if (!gencgc_handle_wp_violation(fault_addr)) if(!handle_control_stack_guard_triggered(context,fault_addr)) interrupt_handle_now(signal, info, void_context); When I rolled back it, SBCL worked fine and built itself (not that I understand anything in it). -- Regards, Alexey Dejneka "Alas, the spheres of truth are less transparent than those of illusion." -- L.E.J. Brouwer |