[comp.sys.next] Installing f2c on the NeXT

rdd@wuphys.wustl.edu (Rakhal D. Dave) (01/02/91)

Here is some more humour for Eric P. Scott. To the rest of you this
might be useful. Please assume the standard disclaimer. Also not
responsible for wet telephone handsets. As always, small thank you
notes are appreciated for this effort.

                        Installing f2c on the NeXT
(f2c is a fortran to C translator. Since the NeXT does not come
with a fortran compiler, I cannot overemphasize its usefulness,
particularly since it is FREE)

Getting f2c:
ftp 128.210.7.22              (Purdue university)
login: anonymous
password: your initials
ftp> cd /pub/next/sources
ftp> binary
ftp> get f2c.tar.Z
ftp> bye
(place in any convenient directory)

Untarring f2c.tar.Z:
  localhost# zcat f2c.tar.Z | tar -xvf -
(this will create a directory "f2c" containing 3 directories: "f2csrc",
"LibF77" and "LibI77" and 2 files f2c.info and f2c.ndx)

Preliminary adjustments within directory f2c before installing:
You will find that the 3 subdirectories of f2c:  f2csrc/   libF77/
libI77/ each contain 2 subsubdirectories: Iris4D and NeXT. You may
safely throw away the subsubdirectory "Iris4D". Then transfer all
the files in the subsubdirectory NeXT other than README and .places
to the subdirectory it lies in. Here are the Unix commands to do
this:
"file" 198 lines, 8937 characters
to the subdirectory it lies in. Here are the Unix commands to do
this:
        cd /f2c
        rm -R f2csrc/Iris4D
        rm -R LibF77/Iris4D
        rm -R LibI77/Iris4D
        mv f2csrc/NeXT/file f2csrc/file
        mv LibF77/NeXT/file LibF77/file
        mv LibI77/NeXT/file LibI77/file
file = all files other than README and .places .  
Note that when you move the
files in the above mv commands you will be replacing some of the
files already present in the target directory. Do not worry about
losing them. Most important replacements are the files called
"makefile" which contain information on compiling the contents of
their corresponding directory.  Now you can safely remove the NeXT
subsubdirectories in each of the subdirectories of /f2c.
        rm -R f2csrc/NeXT
        rm -R LibF77/NeXT
        rm -R LibI77/NeXT

Support files necessary before "make"ing :  In order to compile
the information in the directories f2csrc/   libF77/   and  libI77/
and so make it usable one has to give a "make" command after "cd"ing
to each of them in turn. But for a successful "make" you will need
the following files from extended 2.0 .
Directory: /usr/lib/nib/
Makefile.common
Directory: /usr/include/
ctype.h signal.h   stddef.h   stdlib.h   strings.h errno.h    math.h
stdarg.h   stdio.h    string.h
Directory: /usr/include/sys
errno.h   stat.h   types.h   signal.h
Directory: /usr/include/machine/
signal.h

How to "make": Give commands:
        cd f2csrc
        make
        cd ..
        cd LibF77
        make
        cd ..
        cd LibI77
        make
        cd ..
(When "make"ing within directory /f2c/f2csrc some warning messages
may be displayed. I don't understand their sorce. However, with the
philosophy that alls well that ends well it seems OK to ignore this.
If someone knows about these warning messages do let me know what is
happening. See "Questions" below)
Please note that if I have missed out some necessary file in
/usr/include, the "make"ing process will stop and exit after asking
for that file. You can add the missing file and simply proceed once
again by typing "make". The "make" genie knows about all the previous
work that was done and will not repeat it. Also note that when it
informs you about the missing file, it will give you the filename
as seen from already within the directory /usr/include .

Installing f2c:
        mv /f2c/f2csrc/f2c /bin/f2c
        mv /f2c/f2csrc/f2c.h /usr/include/f2c.h
        mv /f2c/LibF77/libF77.a /usr/lib/libF77.a
        mv /f2c/LibI77/libI77.a /usr/lib/libI77.a

Support files necessary to add from extended 2.0 before f2c becomes
usable:  (I have lost track of whether some of these were already
present in the original NeXT 105) 
Directory: /usr/lib 
libm.a
Directory: /bin
ar*        cc*        file*      kgdb*      nm++*
segedit*   as*        cc++*      g++filt*   ld*        otool*
size*      atom*      ebadexec*  gdb*       nm*        ranlib*    strip*
Directory: /lib
cc1*        collect*    crt0.o      libsys_p.a
cc1++*      cpp*        gcrt0.o     libsys_s.a

Using f2c:  Before f2c is seen in /bin and recognized as a command
I had to reboot. There must be an easier way which I hope someone
lets me know.  
Write a Fortran program: prog.f 
Then give the following commands:
        f2c prog.f  (this will create prog.c in same directory) 
        cc prog.c -lF77 -lI77 -lm  (this will create a.out) 
        a.out 
For some reason a.out was not recognized as a command immidiately when
I was in root. On logging out and logging in as "me" a.out was seen
as a command and executed. Hopefully someone will illuminate me
about this. (Note that a.out was executable in root still it did
not run.) Also note that if you look inside prog.c it will ask you
to compile with :
        cc prog.c -lF77 -lI77 -lm -lc 
I did not however find a
/usr/lib/libc.a on any NeXT with extended 2.0 software. I therefore
omitted -lc in that command and everything works fine. Some
illumination on this is necessary from experts. My programs are
extremely math intensive but omitting this library did not cause
problems. Any idea when this would cause problems ?

The Marvels of f2c:  
1. The executable program a.out generated from
prog.f using the above route works exactly like the f77 compiled
program. The read(5,*) and write(6,*) are correctly interpreted
for the standard input/output. The read and write (#,*) (where #
not equal to 5,6) correctly references or creates a file fort.# .
2. The binary files a.out generated by f77 on a Sun were usually
10% larger than the a.out files generated on the NeXT using the
above route.  
3. While I never managed to get the Sun4 totally free
of background processes to make a useful comparision of speed, I
got the distinct feeling that if the Sun4 had even 1 background
process other than mine, the NeXT 040 would win out.( Note that
this is assuming the NeXT had only this one process running). I will
report with hard facts on this when an opportunity arises.  
4. The compilation time necessary to translate prog.f and compile a.out
is quite negligible. This ofcourse depends on the size of the
program. A 268 line program was translated to a 585 line program
(a large fraction of lines were blank). This took less than 3
seconds.

Questions:  
1. How to get the computer to recognize an addition to
/bin without rebooting.  
2. Why doesn't root recognize a.out.  
3. What corresponds to /usr/lib/libc.a on the NeXT. Why do my programs
compiled as above work without linking libc.a as requested by the
remark lines in the translated C program prog.c .  
4. Apparently the only pieces that are useful are f2csrc/f2c, f2csrc/f2c.h,
LibF77/libF77.a and LibI77/libI77.a . After these are manufactured
by "make" and installed in different directories as described above,
it seems that the remaining stuff, that is the contents of directory
/f2c may be thrown away. I haven't yet done this thinking that
maybe this is referenced during the translation and compilation
process. But I doubt it since, the files libI77.a and libF77.a
generated during "make" are almost as large as the rest of the
stuff put together in their directory. I would appreciate comments
on this.  
5. Any information on the warning messages displayed
while "make"ing f2c. Here is the portion of messages displayed
while "make"ing f2c which are worrisome. (I once again remind the
reader that this did not seem to cause any real problem while using
f2c) The following "make" command was given in directory /f2c/f2csrc
***********************************************************************
localhost# make
cc -O -c main.c
cc -O -c init.c
grep -n . <tokens | sed "s/\([^:]*\):\(.*\)/#define \2 \1/" >tokdefs.h
( sed <tokdefs.h "s/#define/%token/" ; cat gram.head gram.dcl gram.expr gram.exe
c gram.io ) >gram.in
yacc  gram.in

conflicts: 4 shift/reduce
echo "(expect 4 shift/reduce)"
(expect 4 shift/reduce)
sed 's/^# line.*/\/* & *\//' y.tab.c >gram.c
rm -f gram.in y.tab.c
cc -O -c gram.c
cc -O -c lex.c
lex.c:123: warning: useless keyword or type name in declaration
lex.c:127: warning: useless keyword or type name in declaration
lex.c:131: warning: useless keyword or type name in declaration
cc -O -c proc.c proc.c:
In function setbound: 
proc.c:1335: warning: structure defined inside parms
cc -O -c equiv.c
cc -O -c data.c
cc -O -c format.c
format.c: In function do_p1_comment: 
format.c:303: warning: comparison between pointer and integer
format.c: In function do_p1_fortran: 
format.c:620: warning: comparison between pointer and integer
cc -O -c expr.c
expr.c: In function mkprim: 
expr.c:1553: warning: union defined inside parms
*********************************************************************
rdd@dirac.wustl.edu    rdd@wuphys.wustl.edu     rdd@arthur.wustl.edu
<<<<<<<I think therefore I might not be.        Rakhal Dave' >>>>>>>>
*********************************************************************

olson@sax.cs.uiuc.edu (Bob Olson) (01/03/91)

In article <1991Jan2.095723.16706@wuphys.wustl.edu> rdd@wuphys.wustl.edu (Rakhal D. Dave) writes:

   1. How to get the computer to recognize an addition to
   /bin without rebooting.  

Do a "rehash". 

   2. Why doesn't root recognize a.out.  

Because as supplied, the PATH variable for root does not include the
current directory ".". Try ./a.out.

   3. What corresponds to /usr/lib/libc.a on the NeXT. Why do my programs
   compiled as above work without linking libc.a as requested by the
   remark lines in the translated C program prog.c .  

/lib/libsys_s.a, /usr/lib/libNeXT.a for the appkit stuff. You don't
need to explicitly include libsys because the compiler does that for
you. 

   4. Apparently the only pieces that are useful are f2csrc/f2c, f2csrc/f2c.h,
   LibF77/libF77.a and LibI77/libI77.a . After these are manufactured
   by "make" and installed in different directories as described above,
   it seems that the remaining stuff, that is the contents of directory
   /f2c may be thrown away. 

Yes, I would imagine that is fine.

   5. Any information on the warning messages displayed
   while "make"ing f2c. Here is the portion of messages displayed
   while "make"ing f2c which are worrisome. 

You shouldn't have to worry, these are just warning messages from the
compiler. 

bb@sandbar.cis.ufl.edu (Brian Bartholomew) (01/03/91)

In article <1991Jan2.095723.16706@wuphys.wustl.edu>
rdd@wuphys.wustl.edu (Rakhal D. Dave) writes:


> The "make" genie knows about all the previous work that was done and
> will not repeat it.


The "magic" is is kept in the file "Makefile".  The contents of this
file is read and acted upon by the "make" program when you enter the
command "make".  The "Makefile" contains lists of which files are
dependent on which other files, and also contains instructions to
create one from the other.  For example, the result of one invocation
of the C language compiler, an object file "data.o", is listed as
being dependent on the C language source file "data.c".  If the file
data.o does not exist or is older than the file that produces it
(data.c), the corresponding command line (cc -O -c data.c) is
executed.  In this way the whole program is represented as a tree of
dependencies, with the finished program at the top (f2c), C and other
language source files at the bottom (data.c, equiv.c, format.c,
tokens, etc.), and intermediate results from compilers and whatnot in
the middle (data.o, equiv.o, gram.in, lex.c, and so on).

The "make" program is extremely versatile, and is used in the UNIX
world to automate all sorts of things.  It lets you document the
building sequence of a complex program or project, and as a bonus you
can get the computer to read it and do the work for you.  Some UNIX
users might argue that the automation benefit was more important than
the documentation benefit :-)

For more information on "make", type "man make" at a shell prompt, or
search for it in the Digital Librarian in the UNIX manuals.


> Before f2c is seen in /bin and recognized as a command I had to reboot.
> There must be an easier way which I hope someone lets me know.

> For some reason a.out was not recognized as a command immidiately when
> I was in root. On logging out and logging in as "me" a.out was seen as
> a command and executed. Hopefully someone will illuminate me about
> this. (Note that a.out was executable in root still it did not run.)

> How to get the computer to recognize an addition to /bin without
> rebooting.

> Why doesn't root recognize a.out.


The program that reads your typed input in a terminal window, performs
certain manipulations, and starts up programs for you, is called a
"shell".  I suspect that you are running the particular flavor of
shell called "csh", pronounced "C-Shell".  (Yes, that is a pun.  UNIX
programmers like puns.)  The shell knows how to find the programs you
ask for by searching for them in directories named in an environment
variable named "path".  However, as there can be as many as a thousand
programs total in the directories named in your path, the shell
searches each directory in your path at startup time and caches the
names and locations of programs away for future reference.  When you
add a program to one of the directories "on your path", you need to
tell the shell to throw away its cache and re-read the directories, so
that it may notice your new program.  The csh command to do that is
"rehash".  This command will fix all of the problems you have noticed
of this type.

For more information on "csh", type "man csh" at a shell prompt, or
search for it in the Digital Librarian in the UNIX manuals.


> While I never managed to get the Sun4 totally free of background
> processes to make a useful comparision of speed, I got the distinct
> feeling that if the Sun4 had even 1 background process other than mine,
> the NeXT 040 would win out.( Note that this is assuming the NeXT had
> only this one process running). I will report with hard facts on this
> when an opportunity arises.


Sorry, but speed determinations of this type are notoriously hard to
do with any sort of scientific rigor.  For instance, there is no UNIX
machine alive today that will effectively function with "1 background
process other than mine".  You might notice that your NeXT was running
a rather demanding windowing system at the time, and perhaps the Sun
was not.  Or, perhaps it was.


--
"Any sufficiently advanced technology is indistinguishable from a rigged demo."
-------------------------------------------------------------------------------
Brian Bartholomew	UUCP:       ...gatech!uflorida!mathlab.math.ufl.edu!bb
University of Florida	Internet:   bb@math.ufl.edu