1.0.9.53: trivial typo fixes

[sbcl.git] / README

diff --git a/README b/README
index 18578d6..4670fb1 100644 (file)
--- a/README
+++ b/README
@@ -1,3 +1,5 @@
+GENERAL INFORMATION
+

 Welcome to SBCL.
 
 To find out more about who created the system, see the "CREDITS" file.
 Welcome to SBCL.
 
 To find out more about who created the system, see the "CREDITS" file.

@@ -20,3 +22,32 @@ If you'd like to make suggestions, report a bug, or help to improve the
 system, please send mail to one of the mailing lists:
   sbcl-help@lists.sourceforge.net
   sbcl-devel@lists.sourceforge.net
 system, please send mail to one of the mailing lists:
   sbcl-help@lists.sourceforge.net
   sbcl-devel@lists.sourceforge.net

+
+
+SYSTEM-SPECIFIC HINTS
+
+for NetBSD:
+  NetBSD 2.0 and above are required because of the lack of needed
+  signal APIs in NetBSD 1.6 and earlier.
+
+for OpenBSD:
+  OpenBSD 3.0 has stricter ulimit values, and/or enforces them more
+  strictly, than its predecessors. Therefore SBCL's initial mmap()
+  won't work unless you increase the limit on the data segment from
+  the OpenBSD defaults, e.g. with
+    ulimit -S -d 1000000
+  before you run SBCL. Otherwise SBCL fails with a message like
+  "ensure_space: failed to validate xxxxxxx bytes at yyyyy". (SBCL
+  is just allocating this huge address space, not actually using this
+  huge memory at this point. OpenBSD <3.0 had no problem with this,
+  but OpenBSD 3.0 is less hospitable.)
+
+for Darwin:
+  PURIFY (which can be used alone but is also used by the system when
+  saving a new core) uses more stack than the default limit on MacOS
+  X.2.  Therefore, in order to get PURIFY to work reliably, you need
+  to increase the limit, with e.g.
+    limit stack 8192 # for the default shell, tcsh
+    ulimit -s 8192 # for bash
+  before running SBCL.  This is also necessary when building the system
+  from sources, as part of the build process involves saving a new core.