This file presents
* a list of platforms CLISP is known to run on,
* special hints for the following platforms:
    386BSD 0.1
    NetBSD 1.0
    Sun4 (Sparc) under SunOS 4
    Sun3 (68020) under SunOS 4
    Sun4 (Sparc) under SunOS 5.2 or SunOS 5.3
    HP9000/8xx under HP-UX version 8
    HP9000/3xx under HP-UX version 8
    Consensys System V 4.0
    Consensys System V 4.2
    386 UHC UNIX System V release 4
    Onsite System V 4.2
    UnixWare
    SINIX-Z 5.42
    SINIX-N 5.42
    IRIX 3.2.1
    IRIX 4
    IRIX 5
    DECstation 5000, Ultrix
    Apple Macintosh, A/UX
    Amiga running AMIX 2.1 SVR4.0
    Coherent386 4.0.1
    AIX
    Sequent ptx
    Convex C2 running ConvexOS 10.1
    Atari ST/TT running MiNT
    DEC Alpha AXP running OSF/1 1.3 or OSF/1 2.0 or OSF/1 3.0
* hints for porting to new platforms.


List of platforms
-----------------

The Unix version of CLISP is known to run on a variety of machines
and operating systems. The following is a list of successful compiles,
in the format


hardware              OS             compiled by
date                  test-time      email address

(Test-time is the time needed for "make test". Measure user time.)


PC 486/33, 8 MB RAM   Linux 0.98     Bruno Haible
17.11.1992                  415 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
14.12.1992                  418 s
31.12.1992 (gcc233)         384 s
31.12.1992 (gcc233)         377 s
2.1.1993  (gcc233,shm)      359 s
2.1.1993  (gcc233,shm)      363 s
5.1.1993  (gcc233,486)      367 s
15.1.1993 (gcc233,486,shm)  356 s
15.1.1993 (gcc233,486,shm)  362 s
19.1.1993 (gcc233,486,shm)  360 s
29.1.1993 (gcc233,486)      366 s
10.2.1993 (gcc233,486,shm)  359 s
4.3.1993  (gcc233,486,shm)  351 s

PC 486/33, 8 MB RAM   Linux 0.99.7   Bruno Haible
18.3.1993 (gcc233,486,mmap) 337 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
5.5.1993  (gcc233,486,mmap) 346 s
5.6.1993  (gcc240,486,mmap) 366 s
17.7.1993 (gcc245,486,mmap) 368 s

PC 486/33, 8 MB RAM   Linux 0.99.12  Bruno Haible
22.9.1993 (gcc245,486,mmap) 464 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
4.11.1993 (gcc252,486,mmap) 453 s
1.1.1994 (gcc257,486,shm)   483 s

PC 486/33, 8 MB RAM   Linux 1.1.19   Bruno Haible
20.6.1994 (gcc257,mmap)     569 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
27.6.1994 (gcc257,mmap)     515 s
28.6.1994 (gcc257,mmap)     526 s
20.7.1994 (gcc260,mmap)     565 s
27.8.1994 (gcc260,mmap)     582 s

PC 486/33, 8 MB RAM   Linux 1.1.51   Bruno Haible
27.9.1994 (gcc260,gengc)    569 s

PC 486/50, 32 MB RAM  Linux 0.99.14  Marcus Daniels
25.1.1994 (gcc258,shm)      331 s    <marcus@ee.pdx.edu>
25.1.1994 (gcc258,486,shm)  319 s   

Sun 4/70 (Sparc 2)    SunOS 4.1.1    Bruno Haible
19.11.1992 (gcc23)       291 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
22.12.1992 (gcc23)       298 s
28.12.1992 (gcc23)       291 s
1.1.1993   (cc)          424 s
1.2.1993   (gcc23)       268 s
4.2.1993   (gcc23)       276 s
28.3.1993  (gcc23)       276 s
11.5.1993  (gcc23)       274 s
2.11.1993  (cc -O0)      600 s
2.11.1993  (cc -O1)      493 s
3.11.1993  (cc -O2)      649 s
3.11.1993  (cc -O3)      614 s
3.11.1993  (cc)          582 s
14.1.1994  (cc)          632 s
21.7.1994  (gcc260,wide) 754 s

Sun 4/75 (Sparc 2)    SunOS 4.1.3    Marcus Daniels
25.1.1994 (gcc233)       492 s       <marcus@ee.pdx.edu>

Sun 4c (Sparc 1)      SunOS 4.1.2    Martin Sjölin
16.12.1992               679 s       <marsj@ida.liu.se>

Sun 4m (Sparc 10)     SunOS 4.1.3    Bruno Haible
16.1.1993 (gcc233)       208 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
17.1.1993 (gcc233,shm)   203 s
20.1.1993 (gcc233,shm)   186 s
26.6.1994 (gcc)          307 s

Sun 4m (Sun 4/600)    SunOS 4.1.3    Marcus Daniels
25.1.1994 (gcc233,shm)   453 s       <marcus@ee.pdx.edu>

Sun386i               SunOS 4.0.2    Bruno Haible
13.1.1993                            <haible@ma2s2.mathematik.uni-karlsruhe.de>

Sun 4m (Sparc 10)     SunOS 5.1 (Solaris 2)
21.3.1993                387 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
7.9.1993                 500 s

Sun 3                 SunOS 4.1.1    Bruno Haible
17.4.1993               2296 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

Sun 4d                SunOS 5.[23]   Adam M. Costello
2.12.1993 (gcc245)       313 s       <amc@ecl.wustl.edu>

Sun 4m (2 cpus)       SunOS 5.3      Alva L. Couch
23.2.1994 (gcc258)       203 s       <couch@cs.tufts.edu>

Sun 4m (Sparc 10)     SunOS 5.3      Bruno Haible
4.7.1994 (gcc245)        587 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

i386                  Consensys 4.0  Bruno Haible
18.12.1992             --- (*)       <haible@ma2s2.mathematik.uni-karlsruhe.de>
7.9.1993               --- (*)

PC 486/33, 32 MB RAM  Consensys 4.2  Jean-Claude Beaudoin
21.9.1993                            <jbeaudoi@sobeco.com>

HP 9000/825           HP-UX 8        Bruno Haible
27.6.1994               2498 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

HP 9000/835           HP-UX 8        Bruno Haible
27.6.1994               1203 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

HP 9000/720           HP-UX 8.05     Bruno Haible
1.1.1993                 309 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
27.6.1994                335 s
4.7.1994                 360 s

PC 486/33, 8 MB RAM   Coherent 4.0.1 Bruno Haible
16.5.1993 (cc)           470 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
16.5.1993 (gcc140)       413 s

PC 386/33, 16MB RAM   UHC UNIX SysV.4   Blake McBride
20.3.1993 (UHC_1)       1125 s          <blake@netcom.com>
20.3.1993 (UHC_2)       1182 s

PC 486/33, 16 MB RAM  SINIX-Z V5.41  Manfred Weichel
29.7.1993 (gcc245)       383 s       <manfred.weichel@mch.sni.de>
11.7.1994 (gcc258)

PC                    386BSD 0.1     Charles Hannum
26.3.1993                            <mycroft@gnu.ai.mit.edu>

PC 486/33, 8 MB RAM   NetBSD 1.0 Beta   Douglas Crosher
30.8.1994 (gcc245)          582 s       <dtc@stan.xx.swin.oz.au>
30.8.1994 (gcc245,mmap)     522 s       <dtc@scrooge.ee.swin.oz.au>
30.8.1994 (gcc245,shm)      488 s
2.9.1994  (gcc245,gengc)    502 s

DECstation 5000       Ultrix V4.2A   Benlu Jiang
5.5.1993                             <manager@csdeca.cs.missouri.edu>

SGI Mips              IRIX 4         Michael Stoll
11.6.1993                315 s       <michael@rhein.iam.uni-bonn.de>

SGI Mips              IRIX 5         Christian Moen
31.12.1993 (gcc)                     <christim@ifi.uio.no>

SGI Mips              IRIX 5         Martin Cracauer
28.9.1994 (cc)                       <cracauer@wavehh.hanse.de>

RM400 Mips            SINIX-N V5.42  Michael Becker
8.12.1994 (c89)                      <mb12@coconet.de>

IBM Risc System 6000  AIX 3.2        Gabor Herr
22.9.1993                            <herr@iti.informatik.th-darmstadt.de>

DEC Alpha AXP         OSF/1 1.3      Bruno Haible
3.12.1993                141 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
8.1.1994 (gcc257)        145 s

DEC Alpha AXP         OSF/1 2.0      Bruno Haible
2.8.1994 (gcc258)        159 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

PC 486/50, 16 MB RAM  Onsite SysV R 4.2   Sebastian Feldmann
30.10.1993 (cc)          429 s            <snfeldma@teebox.franken.de>
7.11.1993 (gcc233)       348 s
7.11.1993 (gcc245)       345 s

Amiga 3000            AMIX 2.1 SysVR4.0   Michel Loi
22.12.1993 (gcc255)                       <Michel.Loi@lip.ens-lyon.fr>

NeXT                  NeXTstep 3.1   Marcus Daniels
30.10.1993 (cc)                      <marcus@ee.pdx.edu>

NeXT (68040/25)       NeXTstep 3.2   Marcus Daniels
18.1.1994                751 s       <marcus@ee.pdx.edu>
(cc=gcc222)
18.1.1994                627 s
(cc=gcc-222+Mach-VM-singlemap)

PC 486DX2-66          NeXTstep 3.2   Michael Stoll
5.7.1994 (cc)            359 s       <michael@rhein.iam.uni-bonn.de>

Sequent PTX (386/16)  DYNIX/ptx V2.1.0    Marcus Daniels
(gcc233, mmap)          2232 s            <marcus@ee.pdx.edu>

PC                    UnixWare       Alexander Adam
24.1.1994                            <adam@is.informatik.uni-stuttgart.de>

Data General M88000   DG/UX          Pat McClanahan
3.2.1994                 539 s       <mcclanah@dlgeo.cr.usgs.gov>

PC                    BSDI/386 1.1        Atsuo Ohki
16.5.1994                                 <ohki@gssm.otsuka.tsukuba.ac.jp>


When you install CLISP on a machine not mentioned here, please send us a short
note containing the information mentioned above. If you didn't succeed in
building CLISP, please tell us the problems: we will try to make CLISP as
portable as possible.


Special hints for some platforms:
---------------------------------


On 386BSD 0.1:

386BSD can't identify itself. Before executing makemake, you need to create a
program called "arch" that outputs "386BSD". For example:
  $ cat > /usr/bin/arch <<EOF
  #!/bin/sh
  echo 386BSD
  EOF
  $ chmod a+x /usr/bin/arch

Add -DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE to the CFLAGS in the makefile. 386BSD
declares the shared memory and memory mapping facilities (shm*, mmap too?)
in the header files, but does not implement them in the kernel.

In unixconf.h change
  #define IOCTL_REQUEST_T int  to   #define IOCTL_REQUEST_T unsigned long
  #undef IOCTL_DOTS            to   #define IOCTL_DOTS


On NetBSD 1.0:

Add -DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE to the CFLAGS in the makefile. NetBSD
has shared memory and memory mapping facilities but they don't work reliably.

In unixconf.h change
  #define IOCTL_REQUEST_T int  to   #define IOCTL_REQUEST_T unsigned long
  #undef IOCTL_DOTS            to   #define IOCTL_DOTS


On a Sun4 (Sparc) under SunOS 4:

The Sun cc is usable only without the optimization flag "-O". (At least spvw.d
is compiled incorrectly when -O is used.)
It is best to get and install GNU gcc. (Gcc version 2.2 or later required.)


On a Sun3 (68020) under SunOS 4:

In the makefile, I had to add -DNO_MULTIMAP_FILE -DNO_MULTIMAP_SHM to the
CFLAGS, and change
     PACK = tar
to   PACK = /usr/local/gnu/bin/gtar


On a Sun4 (Sparc) under SunOS 5.2 or SunOS 5.3:

For the readline library, you *may* have to add -D_POSIX_VERSION to the CFLAGS
in the readline/Makefile, and modify the line containing SIGNALBLOCK_POSIX
in readline/config.h. I cannot tell anything definitely correct about this.

Make sure your PATH contains the X11/bin directory. Especially xmkmf must be
found. Make sure your LD_RUN_PATH contains the X11/lib directory. Otherwise
the shared X11 libraries won't be found.
For example, you may append ":/usr/openwin/lib" to your LD_LIBRARY_PATH and
replace "-Y P,/usr/ccs/lib:/usr/lib" in the makefile by
"-Y P,/usr/ccs/lib:/usr/lib:/usr/openwin/lib". To make sure these settings are
in effect every time clisp is run, it may then be useful to add the lines
    LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/openwin/lib"
    export LD_LIBRARY_PATH
to the /usr/local/bin/clisp script.

Normally, clisp doesn't use shared memory on SunOS 5 because it tries to
attach more segments that the default limit (6). If you want clisp to use
shared memory, you have to increase this limit: put the line
set shminfo_shmseg=200
into /etc/system, reboot, and continue installing clisp.


On a HP9000/8xx under HP-UX version 8:

If cc had no bugs:
  Choose "cc -Aa -z -D_HPUX_SOURCE" or "c89 -z -D_HPUX_SOURCE" as compiler,
  as described in paragraph 2 of the INSTALL file.
  You need the -Aa flag resp. the c89 compiler because the normal "cc" does not
  expand macros with arguments within constant expressions in preprocessor
  commands like #if.
  Without the -D_HPUX_SOURCE flag many include files are incomplete. When using
  -D_POSIX_SOURCE instead, <errno.h> fails to define ELOOP.
  The -z flag is harmless.
Alas, cc and c89 initialize string arrays declared like
    static char* table[] = { 0?"a":1?"b":"", ..., 0?"x":1?"y":"", };
with NULL pointers!

So get and install GNU gcc. This works for sure.

If you get an error message "./configure: sh internal 1K buffer overflow"
the remedy is either to get and install GNU bash and to enter
  CONFIG_SHELL=/bin/ksh
  export CONFIG_SHELL
before calling "configure".


On a HP9000/3xx under HP-UX version 8:

If you are using GNU gcc 2.4.5 with the HP-UX assembler, in the makefile add
-DHPUX_ASSEMBLER -DNO_ASM to the CFLAGS and remove -fomit-frame-pointer from
the CFLAGS. This way the best optimizations are disabled, but otherwise you
are risking core dumps.


On Consensys System V 4.0:

Choose "cc -I/usr/include" as compiler, as described in paragraph 2 of the
INSTALL file.
Otherwise /usr/ucbinclude/sys/sysmacros.h will be included instead of
/usr/include/sys/sysmacros.h, and this lacks the definition of ctob().

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. The shared memory
facilities of Consensys do not work as expected. This flag prevents CLISP
from using them.

(*) The lisp.run you get is a program that reliably crashes your machine.


On Consensys System V 4.2:

Add -DNO_MULTIMAP_SHM -DSVR4 -DUSL to the CFLAGS in the makefile.
Use "-O", not "-g", as compiler optimization settings in the CFLAGS,
otherwise the ISQRT function may not work.


On 386 UHC UNIX System V release 4:

Add -DNO_MULTIMAP_SHM -DSVR4 -DUSL to the CFLAGS in the makefile.


On Onsite System V 4.2:

Add -DUSL to the CFLAGS in the makefile.
You may need to add -lnsl to the LIBS in the makefile.


On UnixWare:

Add -DNO_MULTIMAP_SHM -DUNIX_SYSV_UHC_1 to the CFLAGS in the makefile.
This is because shared memory does not work, and malloc() returns
addresses in the range 0x080xyzzy.


On SINIX-Z 5.42:

Add -DNO_SINGLEMAP to the CFLAGS in the makefile. Something relating to
mmap() or mprotect() appears not to work.


On SINIX-N 5.42:

If using c89:
  Add -Dunix -DSYSTYPE_SYSV to the CFLAGS in the makefile.
  In /usr/include/sys/signal.h replace the line
    #if (__STDC__ - 0 == 0) || defined(_POSIX_SOURCE) || defined(_XOPEN_SOURCE) || defined(_KERNEL)
  by
    #if defined(__STDC__) || defined(_POSIX_SOURCE) || defined(_XOPEN_SOURCE) || defined(_KERNEL)
  - otherwise no program can include <signal.h> without error.
  Set CPP = C89 -P in the makefile.


On IRIX 3.2.1:

cc is too buggy: it dumps core when compiling spvw.i. You'll see a message
"Fatal error in: /usr/lib/ccom - core dumped".

Get and install GNU gcc.


On IRIX 4:

If you are using cc, choose "cc -ansi" as compiler. cc in non-ANSI mode
fails to expand macros with arguments within preprocessor directives like #if.
Since the compiler rejects 8-bit characters in strings, you will have to
convert the sources to plain ASCII first.
Add  -Olimit 3000  to the CFLAGS in the makefile. This ensures that the
bytecode interpreter will get optimized, which is crucial for performance.
If the compiler signals an internal error in unix.d, pointing to the line
"extern signal_handler signal (int sig, signal_handler handler);",
then comment out that line.


On IRIX 5:

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile.
With IRIX 5.1(.0.1), it is necessary to add -D_POSIX_4SOURCE to the CFLAGS
in the makefile.


On DECstation 5000, Ultrix:

After executing "configure ...", change the first line in makemake from
"#! /bin/sh" to "#! /usr/bin/ksh". /bin/sh apparently doesn't support
function definitions.
Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. Shared memory
facilities do not work: even SHMLBA is not defined correctly in <sys/shm.h>.


On Apple Macintosh, A/UX:

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. Shared memory
facilities do not work: even SHMLBA is not defined correctly in <sys/shm.h>.


On an Amiga running AMIX 2.1 SVR4.0:

Add -DUSL -DSVR4 -DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE to the CFLAGS in the
makefile. If you don't have the GNU assembler gas, then add -DNO_ASM to
the CFLAGS in the makefile. You may need to add -lnsl to the LIBS in the
makefile.


On Coherent386 4.0.1:

If you are using MWC cc:
  First convert the sources to plain Ascii. "cc" barfs on input files
  containing non-Ascii characters even though Coherent uses the PC character
  set.  "cd unix"  "cc -O cv-to-ascii.c -o cv-to-ascii"
  "cp cv-to-ascii to-ascii all-to-ascii /usr/local/bin"  "cd .."
  "all-to-ascii src/* utils/* doc/*"
If you are using GNU gcc:
  First convert the sources to the IBM PC character set Coherent uses.
  "cp dos/cv_lt_pc.c unix/cv-to-ascii.c"
  "cd unix"  "cc -O cv-to-ascii.c -o cv-to-ascii"
  "cp cv-to-ascii to-ascii all-to-ascii /usr/local/bin"  "cd .."
  "all-to-ascii src/* utils/* doc/*"

Then execute the configure scripts using ksh instead of sh.
"cd src"  "ksh configure"  "cd readline"  "ksh configure"

Fix the readline/ subdirectory Makefile: remove the two lines with
the .c.o rule, and set the CFLAGS line to "CFLAGS = -O -DVI_MODE".
"vi Makefile" ... "cd .."

Then execute the makemake script using ksh instead of sh.
/bin/sh doesn't support function definitions.
"ksh makemake > makefile"

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. Shared memory
facilities do not work: even SHMLBA is not defined correctly in <sys/shm.h>.

Then "make". If you are using MWC cc and it stops saying
"Fatal error: EOF in midline", then simply retry, perhaps with less machine
load.


On AIX:

You can't use "cc" as compiler since it wants more than 64 MB RAM to compile
eval.d. You will use GNU gcc without regrets.
Choose "gcc -Dunix" as compiler, as described in paragraph 2 of the INSTALL
file.

Add -DNO_SINGLEMAP -DNO_MULTIMAP_SHM to the CFLAGS in the makefile.


On Sequent ptx:

Add -linet -lnsl to the LIBS in the makefile.


On Convex C2 running ConvexOS 10.1:

Add -Dunix to the CFLAGS in the makefile.
Modify the definitions belonging to CL_MMAP in unixconf.h appropriately.

If you are using gcc and have not -DSAFETY=2 or -DSAFETY=3 set, add
-ffixed-a4 -ffixed-a5 -ffixed-s5 -ffixed-s6 -ffixed-s7
to the CFLAGS in the makefile. This is needed because eval.d and lispbibl.d
use the registers a4, a5 and s5, s6, s7 in a special way.

If using gcc-2.6, compile eval.d without optimization flags (otherwise
eval.d gets miscompiled) and compile io.d without optimization flags
(otherwise gcc crashes).


On Atari ST/TT running MiNT:

Use "gcc -Dunix -U__TOS__" as compiler. The "-Dunix -U__TOS__" flags make
CLISP forget that it will be running on an Atari. MiNT is treated like any
other Unix operating system.

If you are on an Atari TT, add -DATARITT to the CFLAGS in the makefile.
This is because ST and TT have different address space layout.


On DEC Alpha AXP running OSF/1 1.3 or OSF/1 2.0 or OSF/1 3.0:

If cc had no bugs:
  Add  -Olimit 1500  to the CFLAGS in the makefile. This ensures that the
  bytecode interpreter will get optimized, which is crucial for performance.
Alas, I didn't succeed in building a working lisp.run with cc. cc cannot
compile package.d correctly.

So get and install GNU gcc (version 2.5.5 or newer).

On OSF/1 1.3, add -DNO_SINGLEMAP to the CFLAGS in the makefile. The reason is
this that mmap() is not usable: it returns errno=ENOMEM. (The shared memory
facility is not usable either: shmget() works only for segsize < 4112 KB,
shmat() returns errno=EINVAL. But this is automatically detected at
configuration time.)
On OSF/1 3.0, mmap() works.


Hints for porting to new platforms:
-----------------------------------

Choose a reliable C compiler. GNU gcc is a good bet.

Has your machine a weird address space layout?
CLISP assumes that the code and data area as well as the area of malloc'ed
memory have addresses in the lower 16 MB, that is, addresses occupying
only the lower 24 (out of 32) address bits. This allows CLISP to use the
upper 8 bits as tags, for encoding the run time type of Lisp objects.
In case this assumption does not hold, either
* find a way to store 6 tag bits and an address in a 32 bit word, and
  modify lispbibl.d appropriately - not a trivial task -, or
* add -DWIDE to the CFLAGS. This will cause 64 bits (instead of 32) to be
  allocated for every pointer to a Lisp object: 32 for the address, the
  remaining for the tags. This will severely degrade CLISP's efficiency: memory
  consumption will grow by 60% or more, speed will be lowered by 30% or more.
  You will need a C compiler that provides 64 bit integer types; one such
  compiler is GNU gcc (version 2.3.3 or later).
No assumptions about the stack area are made.

If you get an error message mentioning "handle_fault", then generational GC
is not working. Add -DNO_GENERATIONAL_GC to the CFLAGS and recompile.

Has your operating system shared memory or memory mapping facilities?
CLISP tries to use them to save the time for stripping off the tag bits (see
above) before memory accesses. If you get an error message concerning shared
memory, you should add -DNO_MULTIMAP_SHM to the CFLAGS and recompile. If
you get an error message concerning mapped memory, you should add
-DNO_MULTIMAP_FILE -DNO_SINGLEMAP to the CFLAGS and recompile. Doing so
introduces a speed penalty of about 6%. If you still get an error message
concerning mapped memory, you should add -DNO_TRIVIALMAP to the CFLAGS and
recompile.

If interpreted.mem was successfully generated, but lisp.run dumps core when
loading .fas files, you should add -DSAFETY=3 to the CFLAGS and recompile.
Find out which is the least SAFETY level that produces a working lisp.run and
compiled.mem, and tell me about it.

You can check which symbols get defined in lispbibl.d by looking into
lispbibl.h, assuming you are using gcc. For example:
    make lispbibl.h
    grep TYPECODES lispbibl.h

