X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=README;h=4670fb1bd33463d36adf42a6f7fed4d4d17b3ba3;hb=e1905b479292158bd2bacdebb81e27b4da041097;hp=18578d64b7d4fdd3ce6b5de403559688398fe94d;hpb=a530bbe337109d898d5b4a001fc8f1afa3b5dc39;p=sbcl.git

diff --git a/README b/README
index 18578d6..4670fb1 100644
--- 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.
@@ -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-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.