The file natst.C should be copied into $P in place of $P/natst.r
(it is a version that tests for IEEE NaN's as NAs)
execute
	rm -f $P/natst.r
	cp natst.C $P


The old-S q() function causes aborts.  To fix that
	rm -f $F/q/q.r
	cp q.c $F/q
This does not use the Fortran stop statement (which is the operation
that gets in trouble).

-----
You will probably have to make a new version of m4.

You can execute the sysgen procedure and it will tell you if a new
m4 is required.  If this is the case, there are two possibilities.
If your Sun has the optional System V software (in /usr/5bin) then
the easiest thing to do is to edit $C/makehead to define M4 as /usr/5bin/m4.
	chmod +w $C/makehead
The fixed line should look like:
	M4=/usr/5bin/m4

Alternatively, if you don't have /usr/5bin/m4, or if it dosn't work,
you will need to compile your own:
	cd $SHOME/src/m4
	make
Then, you can install src/m4/m4 into an appropriate binary directory or
you can leave it where it is.  (Of course, make sure you don't remove the src
directory later to save space or you will also end up removing your
version of m4).
Execute
	chmod +w $C/makehead
and then edit $C/makehead to define M4 as $SHOME/src/m4/m4.
The fixed line should look like:
	M4=${SHOME}/src/m4/m4
------

Similarly, if you have to compile ratfor from the source in src/ratfor,
just execute make in that directory (after taking the -ly out of the line
of Makefile that creates the executable).  Then, in $C/makehead, define
RATFOR=$SHOME/src/ratfor/a.out


======  floating point flag stuff for Sun 3 machines only =======
You might want to add the flag -f68881 to the lines beginning
        FFLAGS=
        CFLAGS=
        LDFLAGS= 
in $C/makehead and in $QPE/Makefile and
$QPE/S_makefile in order to get compilations to use the 68881 floating
point chip.  This chip is present on all but stripped-down Sun 3/50s.
Another possibility is to use -fswitch to cause the use whatever
floating point hardware is available.  (I think -f68881 is faster
than -fswitch in most cases).  It is important that all 3 of FFLAGS
CFLAGS and LDFLAGS be set consistently if using "-fswitch", -f68881"
or "-ffpa".  It is also possible to control the compilation and loading
floating point options by means of an environment variable,
FLOAT_OPTION.  If you want to use it, look it up in Floating Point
Programmer's Guide for the Sun Workstation.  We recommend putting the
options in the makefile to avoid confusion.  Also, you should probably use
specialized core libraries if you have specified a particular floating
point option.  To do so, change the reference to -lcore into -lcore68881, etc.
You can also add the library /usr/lib/f68881/libm.il to the SYSLIB
entry in $QPE/Makefile and S_makefile, making it read:

SYSLIB = /usr/lib/libF77.a /usr/lib/libI77.a /usr/lib/f68881/libm.il -lm

This uses inline code for some floating point functions rather than subroutine
calls and seems to speed things up.


In order to compile S with the "-ffpa" option, a couple of changes must
be made to the code, due to the way the Sun handles its floating point
accelerator.  In the definition of the routine catchall()
in file $QPE/debug.c,
change the lines:
	catchall(i)
	int i;
to:
	catchall(i, code, scp)
	int i, code;
	struct sigcontext *scp;
and after the line:
	last_signal = i;
add the line:
	if(i == SIGFPE && code == FPE_FPA_ERROR && fpa_handler(scp)) return;
Further, change the routine catchfpe() in file $QPE/comp_util.c to:
	catchfpe(i, code, scp)
	int i, code;
	struct sigcontext *scp;
	{
		if(code == FPE_FPA_ERROR && fpa_handler(scp))
			return;
		longjmp(fpe_buf,1);
	}

Change $QPE/main.c to omit the lines:
	for(i=3; i<10; i++)
		close(i);
There is empirical evidence that this can lead to bus errors on Sun 3 machines.

To make old-S run with the "-ffpa" option, you will probably have to do
something similar.
======= end of floating point flag stuff ========


Under release 4.0, the shared library option modifies the way object
files are bound.  We recommend that you use static binding by appending
  -Bstatic
to LDFLAGS (in addition to the floating point option you might
have used, e.g. -f68881) and to LDRFLAGS.
This binds routines from system libraries into the S executable
and allows the dyn.load function to refer to routines from those libraries.



On Sun 4 machines, the line in $QPE/sys_funs.c (near line 1933) reading 
#ifdef ATT_UNIX
		should be changed to 
#ifndef ATT_UNIX
This comments-out the dynamic loading capability which does not work
on Sun 4 machines.



To load old-S under release 4.0 machine, change the $(F77) line in
$M/Smakefile that loads NEW.S into

	cc $(LDFLAGS) -o $$C/NEW.S $(ALL) $$M/ILIST.a $L/apply $(GRZ) -lF77 -lm

This is necessary because one of the fortran libraries contains a definition
for routine "system" which causes huge amounts of garbage to be pulled
into the load when done in the standard manner.  Unfortunately, the huge
amounts of garbage also result in several undefined routines, such
as _units.  The same sort of change must be made to $F/tty5620/Smakefile
and $F/tty630/Smakefile (for loading dev.tty5620 and dev.tty630).


Apparently, the -O flag to f77 can get into lots of troubles, at least in
conjunction with -fswitch.  One installer reported 35 or so instances
of routines that would not compile in this mode.  They all compiled
satisfactorily when -O was omitted.  This was with Release 3.2, on a
2/170, so things might be better now.
Also, note that -O may require large intermediate files in /tmp
(2Mb was reported to be adequate).

It takes about 2hr to make New S on a SUN 3/280 
then about 1hr to make old S.
The executable files are 2Mb for new S, 1.4Mb for old S.


When the system generation is complete, execute the following commands.
	cd $SHOME/s/.Functions
	cp do.command unix
This installs a special co-process version of the unix() function that
is necessary if you ever want to use the sun() device function.  It tries
to avoid conflicts between S and suncore in signal handling.
