Sun-3 and Sun-4, SunOS 4.1

   o  Tested with /bin/cc, various gcc versions, and with the
      ANSI SPARCompiler 2.0.1 (acc).

   o  For compiling Elk with gcc (2.5.4 or 2.5.7) and the generational
      garbage collector, see the file BUGS.

   o  Dumped executables created on a Sun-4m (SPARCstation 10 or
      SPARCstation 600) do not run on other Sun-4 architectures and
      vice versa.


Sun-4, SunOS 5.2 (Solaris 2.2)

   o  Tested with various gcc versions and with ANSI SPARCompiler 2.0.1.
      See previous section for a comment on a possible gcc bug.

   o  Some versions of gcc (in particular Cygnus gcc) might complain
      about syntax errors in code that uses sigset_t (from <signal.h>).
      This is caused by a bug in the include files; the only fix I know
      is to add -D__STDC__=0 to the cflags in the config file.

   o  "dump" works, but it doesn't know anything about shared objects
      (the dl library doesn't support a way to get hold of the text and
      data segments of dlopen()ed shared objects).  Thus it's a bad idea
      to invoke "dump" if any object files have been loaded into the
      interpreter.

   o  Dynamic loading is based on the dlopen() function of the "dl"
      library.  Here is a short overview of the implementation of
      dlopen-based dynamic loading:
   
         To load an object file, the linker is called by the interpreter
         to produce a shared object from the .o file.  This shared object
	 is then loaded by means of dlopen().

         To allow object files to reference symbols defined by object
         files loaded earlier (the standard dynamic loading semantics
         of Elk), the interpreter keeps tmp the output files (shared
         objects) of all previous linker invocations in /tmp and uses
	 these as input to a each linker invocation.  As a result, one
	 new temp file is created each time an object file is loaded.

         As the linker combines dynamically loadable object files and
         (optional) libraries into shared objects, all dynamically loadable
         files must have been compiled with -fpic or -K PIC (to create
	 position independent code).  Also, all involved libraries must
	 either be shared libraries or must contain position independent
	 code as well.  For example, if you want to use the Motif extension,
	 your Xm library must have been compiled with -fpic.

         A bug in Solaris 2.1 causes dlopen() to fail if more than
         8 shared objects are loaded (which in turn causes the "load"
         primitive of Elk to signal an error).  This restriction doesn't
         exit in Solaris 2.2.

         You can use the -v option of Elk to see the actual linker options
         when an object file is loaded.

   o  You probably can't use GNU g++ (gcc) 2.5.7 (and earlier versions)
      to compile dynamically loadable Elk extension written in C++.
      A bug in g++ causes it to produce position-dependent code if static
      constructors are used, although -fpic has been specified in the
      command line.  This renders the resulting ELF object files unsuitable
      for dynamic loading.


DECstation 5100, Ultrix 4.2

   o  Prototypes have been disabled in the config file, as cc seems to
      have problems with certain forms of prototype declarations (I think
      this is a bug in the C-compiler).

   o  The LDFLAGS "-Wl,-D,800000" are required for dynamic loading to work.

   o  You have to create "-G 0" versions of all X libraries to be able to
      dynamically load the X11 extensions of Elk (the MIPS linker requires
      this).


SGI IRIS Indy, Irix 5.0

   o  I couldn't find any Motif include files, so the Motif extension
      remains untested.

   o  See SunOS 5.x above for information about dynamic loading.

   o  "dump" doesn't work.  I didn't have the time yet to investigate
      the problem.  Any takers?


SGI Indigo/Crimson, Irix 4.0

   o  See the remarks about "-G 0" libraries and LDFLAGS under
      "DECstation" above.

   o  To avoid a bug in the Irix linker, you have to compile the program
      util/sgihack.c and invoke it with the interpreter executable as an
      argument (once each time you have created a new executable).
      Failing to do so may cause the linker to complain about an attempt
      to redefine a linked-defined symbol when you try to load multiple
      object files into the running interpreter.

   o  Dynamic loading and "dump" do not work with the Irix linker
      version 3.1.  Dynamic loading causes the linker to complain about
      an unknown section in the a.out file; this is a bug in the linker.
      You may want to set "load_obj=" in config/system and use
      $install_dir/linkscheme to statically link the interpreter with
      extensions and/or an application.

   o  On some Irix installations, the C compiler reports that the include
      file /usr/include/cmplrs/stsupport.h is missing.  In this case,
      complain to your system administrator.  A quick fix is to mkdir
      include/cmplrs and touch include/cmplrs/stsuppor.h; the contents
      of the file isn't really required.

   o  Incremental garbage collection isn't supported, as the mprotect()
      syscall doesn't seem to exist (it's in the C library, but using
      it results in a `Bad system call').


SGI Personal IRIS, Irix 3.3

   o  On this platform, Elk has only been tested up to version 2.0.

   o  Dynamic loading doesn't work (or only with trivial files);
      this seems to be a generic problem with older versions of the MIPS
      linker.

   o  I have not been able to compile Elk's Xt extension; it looks like
      something is wrong with SGI's X11 include files under Irix 3.3.


Sony NWS 3xxx, NEWS-OS 4.1

   o  On this platform, Elk has only been tested up to version 2.0.

   o  See "Irix 3.3" above for a problem with the MIPS linker.


HP 9000/700, HP-UX 9.0

   o  I have set wait3=no in the system file, because this function has
      a non-standard third argument in HP-UX 9.0.

   o  See HP-UX 8.0 below for information on dynamic loading and "dump".
      "dump" doesn't really work, because HP in their infinite wisdom
      have removed the MAP_REPLACE flag for mmap() in HP-UX 9.x.

   o  The incremental garbage collector doesn't work (see the file
      BUGS); I didn't have the time yet to investigate this.

   o  The Athena widgets are not included with HP-UX 9.0; delete
      "lib/xaw" from the Makefile.

   o  You may want to use the HP-UX site file from config/sites.


HP 9000/700, HP-UX 8.0

   o  Dynamic loading is based on the shl_load() interface to the dynamic
      linker of HP-UX.  If you are writing your own extensions, compile
      them with the option +z and use $install_dir/lib/makedl to link them.
      The load-libraries are simply shl_loaded before the files passed to
      the "load" primitives.  Each load-library is only loaded once.

   o  "dump" works with shared libraries (most of the time; it still fails
      occasionally), but read the comment at the beginning of
      src/dump-hp9k.c.

   o  The incremental garbage collector doesn't work, because there is
      no mprotect() system call.

   o  The Athena widgets are not included with HP-UX 8.0; delete
      "lib/xaw" from the Makefile.

   o  The Motif extension can't be built; the linker crashes with
      segmentation violation while building lib/xm/xt/xt-motif.pre.

   o  You may want to use the HP-UX site file from config/sites.


HP 9000/800, HP-UX 7.0

   o  No dynamic loading yet.
   
   o  I couldn't find a working version of X11 or Motif.

   o  The shell seems to be broken; the "build" script in the directory
      scm creates a garbled Makefile.local.  I don't have the time to
      investigate this; you can copy the *.scm files into the
      destination directory by hand instead of calling "make install".


HP 9000/300, HP-UX 7.0

   o  The Xt/Xaw extension crashes when linked with X11R4.

   o  I haven't tested the Motif extension.


Siemens Nixdorf MX300I (Intel 80386), System V Release 4 (5.40)

   o  On this platform, Elk has only been tested up to version 2.1.
      The following notes apply to Elk 2.1:

      o  Doesn't work with the BSD C-compiler.
   
      o  The C-compiler prints several warnings, all of which can be
	 safely ignored.

      o  Dynamic loading doesn't work because of a bug in the dynamic
         linker.  The linker, when attaching a shared object to the
         running program by a call to dlopen(), refuses to resolve
         against symbols defined by the program.  This means that
         dynamically loadable extensions couldn't use anything
         exported by the interpreter kernel (e.g. all the primitives).


Convex C230, ConvexOS 10.1

   o  "dump" has not yet been implemented on this platform
   
   o  Dynamic loading of object files is not supported by this OS version.

   o  The C compiler prints several ``function f has return(e); and return;''
      messages; don't worry about them (the compiler plays lint, but doesn't
      recognize NOTREACHED directives).  Also, don't worry about the
      assembler warnings that are printed when compiling src/cont.c.


IBM RS/6000, AIX 3.2

   o  Neither "dump" nor dynamic loading work.  I have received code to
      support dynamic loading from two people, but it is so complex and
      affects so many files that I didn't have the patience yet to
      integrate it into Elk.

   o  To support linking the interpreter with extensions statically,
      you *have* to use the $install_dir/lib/linkscheme shell script;
      it contains special code to build an `export list' to prevent
      the AIX linker from `garbage collecting' the extensions.

   o  Make sure to *not* compile Elk with -O; I believe the optimizer
      is buggy.

   o  Some AIX 3.2 systems still seem to run X11R4 (or is that X11R3?).
      In this case "make" complains that it can't find the include file
      <Xaw/Panner.h>.  You have to edit lib/xaw/build, remove all
      occurrences of Panner, Porthole, Repeater and Tree, run
      "make distclean" in lib/xaw and start over.


Integrated Solutions 680x0, 4.3BSD, Greenhills cc
and VAX, 4.3BSD

   o  I haven't tested the X extensions.

   o  The C compiler may print a few warnings when compiling lib/unix/wait.c.


386/486-PC, UNIX System V/386 3.2 (Interactive)

   o  I couldn't really find out how to set the CFLAGS on this type
      of system.  SIG_BLOCK, gid_t and other POSIX definitions are
      only defined if _POSIX_SOURCE is defined, but this somehow doesn't
      make sense.  I have only managed to build a minimal version of
      Elk (with V7 signal semantics and other restrictions).

   o  No dynamic loading, no X11.
   
   o  Some versions of Interactive UNIX seem to have a broken optimizer.
      If you suspect that you have such a system, edit the config file
      and remove -O from the cflags.


386/486-PC, 32-bit gcc (DJGPP) and `go32' DOS extender

    o  As the typical DOS machine doesn't have a fully functional UNIX
       shell, sed, etc., you have to cross-localize the source tree on a
       UNIX machine (i.e. create all the localized Makefiles, create
       include/config.h, etc.).  To do so, just copy the DOS config file
       to config/system (or make a link), edit config/site, and call

          make localized.zip

       This cleans the source tree, performs the necessary localizations,
       and packages a minimal distribution into a zip file.  You can
       then FTP the zip file to the DOS machine and run `make' there.
       The zip file basically contains the interpreter sources, the Scheme
       files needed at runtime, the extensions in lib/misc, and the
       localized Makefiles and include files.

    o  There are a few trouble spots you should watch out for.  Some versions
       of `make' under DOS (Ndmake?) can't handle the macro $(MAKE) that
       is defined at the beginning of all Makefiles.  If this is the case
       on your system, forget the Makefiles and run "make -f Makefile.local"
       in each directory.  You may have to replace $(O) in src/Makefile.local
       by *.o to avoid command lines that are too long for the DOS shell.
       You have to delete the line beginning with "../../scripts/makedl"
       in misc/Makefile.local.


386/486-PC, 386BSD (or is it FreeBSD?), unknown version

   o  I haven't tested the X extensions.

   o  Dynamic loading of object files doesn't work; the linker just
      crashes with segmentation fault.

   o  The UNIX extension is unusable.  <unistd.h> defines several
      _PC_* symbols, although pathconf() and fpathconf() don't seem
      to exist.  I don't have the time to invent a workaround for this.

   o  There was no <alloca.h> on the system where I compiled Elk, thus
      I have set include_alloca_h=no in the config file.

   o  The -Di386 is required to enable the compiler to compile <a.out.h>.

   o  -ansi isn't in the cflags, as the option causes gcc to incorrectly
      compile the "static inline int __sputc" declaration in <stdio.h>
      (__sputc ends up as being multiply defined at link time).

   o  The compiler warnings about ALIGN being redefined can be ignored.


NeXT workstation, MACH/NeXT-OS 3.2

   o  For the UNIX extension to compile correctly, you have to insert
      #define _POSIX_SOURCE as the very first line in lib/unix/wait.h.
      I obtained access to a NeXT only at the last minute and didn't
      have the time to invent a clean fix for the underlying problem.

   o  Dynamic loading is implemented by means of the rld_load() library
      function.  Due to what I think is a bug in rld_load(), it only
      works sometimes.  In particular, it is not possible to load the
      UNIX extension.

      The source of the problem seems to be that sometimes the string table
      of the newly loaded object file gets truncated when being mapped into
      memory by rld_load().  You can observe the problem by inserting a
      statement like "write(1, strtab, sym_cmd->strsize);" right after
      the line beginning with "strtab =" in src/stab-macho.c.


386/486-PC, Linux

   o  Elk has been reported to work under Linux (except for dynamic loading),
      but I couldn't test it personally.  You can find a config file in
      config/untested.



X Window System

   o  You need either X11R4 or X11R5 to use the Elk/X11 interface.
      If you are still running X11R4, edit the file lib/xaw/build
      and remove the lines referring to the Athena widgets that are
      new in X11R5 (panner, porthole, repeater, and tree).


OSF/Motif widgets

   o  You need at least Motif 1.1 to use the Elk/Motif interface.
   
   o  If you are running X11R5 make sure that it has been compiled with
      the symbol MotifBC set to YES in site.def.
