F2C for BEOS (dr8)

This is a port of AT&T's f2c for the BEOS. Using f2c, via the f77 shell
script, one can easily port the few old, but essential, fortran programs
to the Be.

To install the header file, the binaries and the libraries execute the
"Install" script. Don't forget to add $BIN to your PATH variable.

To recompile this package just execute the "Make" script. This script 
will compile f2c and the runtime libraries libF77 and libI77. Next
it will call the "Makelib" script which generates the libf2c.a and 
libf2c.so. Finally the "Install" script places the include file, the
binaries and the libraries in the appropriate places.

Remarks about the f2c Be port:

- due to the fact that Be's fscanf does not return EOF as expected
  I had to make a little routine checkeof() as a workaround (see
  src/format.c). Be! please fix fscanf!

- due to fact that Be does not have the UNIX stdio structures some changes
  were necessary in a number of routines in libI77. Compare the *.org
  routines with the modified versions (one can also compile with the
  NON_UNIX_STDIO flag in which case the changes are not used).

- to get the system to link I had to add erf.c (Be! please add to libBe.so
  or libm.a).

- also to get the f77 script working I needed the program getopt (source
  in getoptprog.c, Be! please add to /bin).

- due to the fact that it is currently impossible to make shared libraries
  that call routines in the main program I had to make libF77/main.c
  dummy and explicitely link it whenever linking the fortran main 
  program (it is f2cmain.o in $INC). Apropos, the Be/MW shared library 
  policy is a major pain in the neck. The requirement that a shared library 
  has to resolve all its symbols is making it impossible to create shared 
  libraries that reference eachothers symbols (wihtout having to resort to 
  dummy definition techniques which defeat the purpose of the initial
  requirement anyway). Linux and 80% of the other Unixes are more flexible
  in this respect (and they don't all come crashing down because of wrong
  shared libraries linked to the wrong programs). Anyway, Be's solution
  is still a little better than M$'s DLL's. I know Jon's arguments in favor
  of this scheme, but not every sl is an add-on.


-- Fons.Rademakers@cern.ch