Sun-3 and Sun-4, SunOS 4.1

   Works.  Tested with both /bin/cc and various gcc versions.

   "dumped" executables created on a Sun-4m (SPARCstation 10 or
   SPARCstation 600) do not run on other Sun-4s and vice versa.


Sun-4, SunOS 5.2 (Solaris 2.2)

   Works (tested with various versions of gcc).

   Dynamic loading is based on the dlopen() function of the "dl" library:
   
      To load an object file, the linker is called by the interpreter
      to make 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 in /tmp the output files (shared
      objects) of all previous linker invocations 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.

      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.

      As the linker combines dynamically loadable object files and
      (optional) libraries into shared objects, all dynamically loadable
      files must have been compiled with -fpic (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.

   "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.


DECstation 5100, Ultrix 4.2

   Works.  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).

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

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


SGI IRIS Indigo/Crimson, Irix 4.0

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

   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.

   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 set
   "init_objects=yes" in config/site.


SGI Personal IRIS, Irix 3.3

   Works at least up to release 2.0 of Elk (I couldn't test newer
   versions; we don't have this Irix release any longer).

   Dynamic loading doesn't work (or only with trivial files);
   this seems to be a generic problem with older versions of the MIPS
   linker.  You may want to set init_objects=yes in config/site.

   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

   Works (at least up to release 2.0 of Elk).
   
   Dynamic loading doesn't work (or only with trivial files);
   this seems to be a generic problem with older versions of the MIPS
   linker.  You may want to set init_objects=yes in config/site.


HP 9000/300, HP-UX 7.0

   The interpreter, dynamic loading, "dump", and the Xlib extension
   work.  The Xt/Xaw extension crashes when linked with X11R4.
   Haven't tested the Motif extension.


HP 9000/700, HP-UX 8.0

   Works.

   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 scripts/linkext-shl 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.

   "dump" works with shared libraries, but read the comment at the
   beginning of src/dump-hp9k.c.

   I couldn't test the Xaw extension, as there are no Xaw include files on
   our system.  The Motif extension doesn't really work; I don't know why.

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


HP-UX 9.0

   HP-UX 9.0 isn't supported yet.  Users who attempted to install a
   beta test version of Elk 2.1 on their machines running HP-UX 9.0
   reported several problems.  You can find a message from Tor Lillqvist
   offering fixes for most of the problems in the file contrib/hpux-9.0.


HP 9000/800, HP-UX 7.0

   Works, but no dynamic loading yet.  Didn't find a working version
   of X11 or Motif.


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

   Works, but not with the BSD C-compiler.  The C-compiler prints
   several warnings, all of which can be safely ignored.

   Dynamic 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

   Works.  "dump" has not yet been implemented.  Dynamic loading of
   object files is not supported by this OS version.  The X11 and
   Motif extensions seem to work fine.

   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

   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.

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

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

   The X11 extensions seem to work.  When making the X extensions,
   don't worry about tons of linker warnings about replacing import
   versions of symbols from the X libraries.


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

   Works.  Haven't tested the X extensions.


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

   Works.  No dynamic loading.  Haven't tested the Xaw extension
   (there are no Athena widgets); the Motif extension works fine.

   `-lsocket' may have to be given when linking with the X libraries.


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

    Works (amazingly, even dynamic loading and dump work).

    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.

    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/linkext-ld"
    in misc/Makefile.local.


386/486-PC, 386BSD 0.1

   Works, but haven't tested the X extensions.

   Because of a mysterious bug in the linker, dynamic loading of
   object files only works if the interpreter has been linked by
   supplying absolute pathnames for the .o files.  Thus you might
   want to call the scripts/linkscheme shell script once to create
   an instance of the interpreter that works:

      scripts/linkscheme scheme

   and use this a.out file instead of src/scheme.

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

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

   -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).

   The compiler warnings about ALIGN being redefined can be ignored.


NeXT workstation, MACH/NeXT-OS 3.0

   Works.  Dynamic loading is implemented by means of the rld_load()
   library function. 


386-PC, Linux
Harris Tahoe, CX/UX 6.2

   Elk has been reported to work on these platforms, but I couldn't
   test it personally.  You find config files for these systems
   in config/untested.



X Window System

   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

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