                Instructions for installing NetHack 3.4
                           on a UNIX system
                =======================================

0.  Read this entire file before starting, and come back to the Notes
    below if you have any problems.  If you are trying to use X11,
    also read all of win/X11/Install.X11, or read win/Qt/Install.Qt
    if you are using Qt or KDE under X11.  For help in controlling
    and running the game after it is installed, see the '?' command
    within the game and doc/Guidebook (non-installers want to know
    about those things too).

1.  Make sure all the NetHack files are in the appropriate directory
    structure.  You should have a main directory with subdirectories
    dat, doc, include, src, util, sys/share, sys/unix, win/tty, win/X11,
    and win/Qt.  You may have other subdirectories under sys and win,
    but they will not affect compilation for a UNIX system.  If you do
    not follow this structure, the Makefiles will not function properly.
    The .c files for the main program belong in src, those for utility
    programs in util, and UNIX-specific ones in sys/unix.  All the .h
    files belong in include, the documentation in doc, and assorted
    data files in dat.  Some UNIX versions may also be interested in
    sys/share's random.c or its lex/yacc output, as explained in note 11.
    (A more detailed explanation of the directory structure may be found
    in Files, which should be in the top directory.)

2.  Your Makefiles may still be in sys/unix with tags on the end of them.
    If so, run "sh setup.sh" in that directory to distribute the Makefiles
    to places they can do their work.  (If later official patches change
    these Makefiles, setup.sh should be rerun to make sure you use the
    current copies.)

3.  Go to the include subdirectory and edit config.h according to the
    comments to match your system and desired set of features.  Similarly
    edit unixconf.h.  Please see the "Notes:" section, below, for some
    configuration hints for particular systems.

4.  If you want to, look through system.h.  This file attempts to match the
    types for system calls and library routines with various flavors of
    operating systems.  Leaving this file alone is unlikely to cause worse
    problems than lint errors, but it's worth checking if you get compile
    errors, especially if you have an unusual system.

5.  Go to the src subdirectory and look at the top of topten.c.  You may want
    to change the definitions of PERSMAX and PERS_IS_UID here to get different
    behavior from the high score list.

6.  Edit the top sections of the src and util Makefiles.  (If you are doing
    a full recompile, or if you got your files from someplace besides the
    official distribution, type 'touch makedefs.c' to make sure certain files
    (onames.h, pm.h) get remade instead of relying on the potentially
    troublesome timestamps.)  Then type 'make' in src and go get a cup of
    coffee or take a nap, depending on the speed of your system.  You should
    now have created the game executable.

7.  Go back to the top directory and edit that Makefile, explaining where
    you want everything to be installed.

    Make sure that you follow the comments about setting GAMEDIR -- the
    installation process will wipe out the contents of the directory you
    point it at, under the assumption that it's debris from an old version
    of NetHack.  If this is not the case, you'll want to install somewhere
    else, or comment out the rm under the install target.

    The Makefile assumes you want to run NetHack setuid 'games' to cut down
    on possible tampering; it's fairly straightforward to comment out the
    appropriate chmod if you don't want that, or to change any of the rest
    of the procedure.  (Note that if you don't want to run NetHack either
    setuid or setgid, and people in more than one group will be playing it,
    you'll need to go back and set FCMASK to 0666 in unixconf.h and let
    everybody fiddle with the files NetHack creates.)

    If the tbl, nroff or col commands are not available on your system,
    edit the doc/Makefile and change the GUIDECMD as directed.

    Type 'make all' from the top directory to set up all the auxiliary
    files the main executable will use.  Then become root if necessary and
    type 'make install'.  Everything should now be set.

8.  Read doc/recover.man or doc/recover.txt to learn how to use the recover
    program.  The recover program can be used in case of a crash to recover
    a game that was in progress.  The recover command is installed in the
    GAMEDIR by default.

Notes:

1.  Save files and bones files from previous versions will not work with
    NetHack 3.4.  Don't bother trying to keep them.

2.  To install an update of this version of NetHack after changing something,
    type 'make update' from the main directory.  If you created the new
    version yourself, it should be safe to use 'make update' as long as you
    did not add, delete, or reorder monsters or objects and you did not change
    the format of saved level files.  If you did any of these things, you
    should also remove any saved games and bones levels.  (Trying to use such
    files often produces amusing but useless confusions on the game's part.)

3.  If you insisted on doing the final installation by hand, you probably
    forgot to make a save directory.  If you don't go back and do this, you
    won't be able to save games.

4.  If you get unexplained deaths by trickery, you are probably running
    NetHack on a bunch of workstations, but you have overlooked the NETWORK
    definition in unixconf.h that is necessary in that configuration.

5.  If spurious characters appear on the screen while throwing, kicking,
    zapping, etc., it is likely that you have linked the source to the wrong
    library or mistakenly defined/undefined TERMINFO.  A number of systems,
    such as Xenix, support both the termcap and terminfo terminal capability
    libraries.  In such cases, the TERMINFO definition in unixconf.h and the
    WINTTYLIB definition in the source Makefile must correspond.

    If your terminal library does not provide suitable delays, NetHack will
    try to fake its own if you set the nonull option.

6.  Since NetHack overflows the stock C preprocessors for AT&T 3b1 and 3b2
    systems ("too many defines"), we are including an alternate preprocessor
    to allow these folks to compile.  This is the DECUS cpp by Martin Minow,
    slightly modified by Kevin Darcy to use larger buffers, be less verbose,
    and handle strange constructs in AT&T's include files.

    To use this preprocessor, unpack the cpp* files found in sys/unix into
    some handy directory (util will do).  For the AT&T machines mentioned
    above, nothing needs to be configured; you should get a working cpp by
    merely typing "make -f makefile.txt".  To get your compiler to use the
    new cpp, you will have to add to CFLAGS in src/Makefile and util/Makefile.
    If you put the cpp files in /foo/bar/util, add "-B/foo/bar/util/ -tp"
    for a 3b1 or "-Yp,/foo/bar/util" for a 3b2.

    For any other machine whose preprocessor can't handle the NetHack source,
    you'll have to play it by ear.  The preprocessor has many esoteric
    configuration options, but most probably you will only need to change
    the flags in makefile.txt, and then refer to your compiler's documentation
    to find the appropriate CFLAGS for the NetHack Makefiles.  (The SunOS flag,
    for instance, would be "-Qpath /foo/bar/util", although the native cpp
    has no trouble with NetHack.  So much for standardization.)

7.  If you are trying to compile NetHack on an AT&T 3B that is running an
    OS earlier than SVR3, you are likely to have problems with overflowing
    symbol tables.  This can be worked around by editing the source Makefile
    to make the Sys.3B2 target work more like the SysV-AT target, adding
    -DDUMB to CFLAGS and DUMB.Setup to the Sys.3B2 dependency line.  The
    compiler provided with later versions of the OS has a large enough
    symbol table that it does not need this workaround.

8.  If NetHack seems to compile fine, starts up, allows you to pick a
    character, and then hangs indefinitely, gets a segmentation fault, or
    traps you in a single room on the first level, you might try changing
    the schar and uchar definitions in config.h to short ints.  This problem
    is known to occur on the AT&T 3B series, Silicon Graphics Irises, and
    IBM systems (PC/RT & RS/6000) running AIX, and may occur on other
    computers as well.

    This problem is really most likely caused by having a non-__STDC__
    compiler with char's unsigned by default.  Since some such compilers
    don't understand the new "signed" keyword, and others don't have signed
    characters to use (the 3B2 line falls into this category), "signed"
    is #ifdefed away for them.  If you are sure your compiler can deal
    with it, you can add your compiler to the __HC__ case in tradstdc.h.

    Alternatively, if the compiler supports a command line switch for
    setting the default char type to signed, you could try setting it in
    the Makefiles.  The appropriate switch for SGI Irises with MIPS C
    compiler is "-signed" and for RS/6000's with standard cc "-qchars=signed".
    (SGI machines running IRIX 4.0.x have a compiler close enough to
    standard to suit NetHack, so you may merely use the suggested flags
    in the Makefiles.)

    Note that at least RS/6000's seem to like changing the default to
    signed better but there is also a problem:  The lexers created by
    the standard lex program in AIX may come out faulty when this switch
    is used (known to happen at least in AIX 3.1.3), so you may have to
    use an alternative, like flex, which is available at major archive
    sites (see notes 10 and 11).

    By AIX 3.2.5, this whole problem should be taken care of automatically
    (but AIX_31 should still be defined in unixconf.h for other reasons).

9.  Under SCO UNIX, you may have all sorts of complaints about
    include/obj.h.  Go to the file and uncomment the marked line, working
    around the fact that SCO's system include files preempt a major
    NetHack structure name.  Also, there are difficulties with SCO's cc
    that thus far have been solved only by changing compilers; one report
    says gcc-NetHack works, and another says rcc-NetHack can be made to
    work by defining NOTSTDC, applying note 8, and compiling with -tinfo
    and -xenix.  The cc problems are old enough that a new, working
    version may have been released by this time.

10. Xenix/286's lex generates a faulty lexical analyser from lev_comp.l.
    The beta-release of flex 2.3 (available from uunet, osu-cis,
    prep.ai.mit.edu, etc.) can be used to generate the lexer.
    The only change to flex is to change "#define yyleng (yy_cp - yy_bp)"
    to "#define yyleng (int)(yy_cp - yy_bp)" in flex.skel.
    Flex is not needed with Xenix/386, as its lex generates a proper lexical
    analyser.  [Xenix instructions by J.T. Conklin]

11. If your system does not have a lex/yacc or flex/bison combination
    capable of producing the dungeon and level compilers, lex and yacc
    output from one of our development systems can be found in sys/share.
    Unfortunately, this output is less portable than the rest of the code,
    as it contains skeleton parsing code provided by the specific vendor
    who has no particular incentive to make such skeletons portable, but
    the output works on most systems.  To try it on yours, copy dgn_comp.h
    and lev_comp.h to include and dgn_lex.c, dgn_yacc.c, lev_lex.c, and
    lev_yacc.c to util.

12. Yes, Virginia, you compile NetHack for a NeXT as if it ran UNIX instead
    of Mach.  Just tell NetHack you're a BSD system (Mach is extremely
    close to BSD UNIX for traditional system calls, so this is also a
    likely thing to try for any other programs you want to compile).

    If you get errors when starting nethack warning that "Setuid execution is 
    not allowed", you might want to re-install using the setgid option instead
    (see Note 7 above, and the setgid comment in the toplevel Makefile).

13. If you are using Solaris 2.x (aka SunOS 5.x) you shouldn't have to
    do any system configuration -- this is the default.  In case it is
    messed up, follow these instructions.

    Solaris is basically a SVR4 system, not a BSD system.  Therefore, you
    configure config.h and unixconf.h as per a SVR4 system:

	config.h: UNIX, TTY_GRAPHICS
	unixconf.h: SYSV, SVR4, TERMINFO, POSIX_JOB_CONTROL, POSIX_TYPES

    X11_GRAPHICS does work.  Do not define OPENWINBUG.  You may safely define
    NETWORK, TEXTCOLOR if desired.  Other #defines in these files may be
    defined too, as needed.  Just make sure that the set mentioned here are
    not misdefined, or your compile will fail (do _not_ define BSD or SUNOS4).
    Unless you are using gzip you will probably want to define COMPRESS to
    be "/usr/bin/compress".

    When compiling, make sure that you use the ANSI C SVR4 compatible
    compiler, /usr/bin/cc, or gcc, but _not_ ucbcc.  The lattermost will
    not work.  After this, you should get a clean compile.

    Also, it is recommended that you use FLEX instead of the standard
    lex bundled with Solaris 2.x (even if that last one should work ;-).

14. If your machine is a 286, 386, or 486 running an appropriate OS, you
    may wish to use the console speaker driver included in
    sys/unix/snd86unx.shr.  This will allow audible music to be played
    on your console speaker in certain appropriate game situations.  The only
    modification to the main-line code needed to enable use of the driver
    is defining UNIX386MUSIC or VPIX_MUSIC in unixconf.h.

15. If you are trying to cross-compile for another system, there is some
    support in the src and util Makefiles, but there are still other
    complications.  It may well be best to make another copy of util,
    util2, to compile target copies of makedefs, lev_comp, and recover
    (duplicating the cross-compilation settings from the src Makefile)
    without disturbing the main build.

    You can use the host makedefs for everything but "makedefs -v", which
    creates include/date.h, which provides various sanity-checking values
    for making sure files read by NetHack at run-time are compatible.
    These values depend on the endianness of your processor, its type
    sizes, and its compiler's idea of struct packing.  Your host and target
    computers may disagree on these things, so you'll need to build a target
    version of makedefs, run "makedefs -v" on your target, and bring the
    resulting date.h back for the builds on the host.  (Making sure the host
    makedefs doesn't decide it needs to overwrite it for you. :-)

    You also need a target version of lev_comp, and to provide it with all
    the dat/*.des files, and copy all the resulting *.lev files back for
    packaging on the host.

    For recover, you just want the target binary to install on the target.
