short version:

   the in tree fortran appears to have bugs.  the script 'f2c-f77', part
of the lang/f2c package does a better job in the problem cases I've looked
at, but 'f2c-f77' is a funny name that doesn't get picked up by configure
scripts.  So, what to do before the in tree fortran is fixed is the
question.


long version:

I've noticed some problems with fortran lately that affect a handful of
packages.  The basic problem is that the in tree fortran compiler
(f77,g77,fort77), from egcs doesn't totally work [more on that later] on
all platforms. So that leads to a question as to how to handle fortran in
packages.  

The lang/f2c package is a fortran to C compiler which includes a shell
script 'f2c-f77' which calls 'f2c' and then 'cc' to emulate a "real" 'f77'
command.  This combination seems to work quite well and produces working
output on the platforms I've tried on (i386, m68k, sparc, pmax).  However,
the name 'f2c-f77', which was chosen to not conflict with the names of the
in tree compiler (f77,g77, and fort77), is non-standard in the sense that
autoconf configure scripts won't look for 'f2c-f77' and for that matter no
one else will either unless they know about it.

In addition to the lang/f2c package, we have the lang/fort77 package.
This package is a perl script which does essentially the same thing as
'f2c-f77' sh script and is called 'fort77'.  In fact I'm not sure why
one wouldn't just link 'fort77' to 'f2c-f77' instead of using this
package, but thats another issue.  On pre-1.4* machines this gave the
functionality of a real fortran compiler in the sense that configue
scripts would find it since 'fort77' is a "standard" name for the fortran
compiler.  To prevent name conflicts in NetBSD-1.4*, the 
lang/fort77/Makefile has:

  lang/fort77/Makefile:
       .if exists(/usr/bin/fort77)
       IGNORE=                 "is part of your NetBSD distribution"
       .endif

       DEPENDS+=               f2c-19980913:../../lang/f2c


ok, so thats what we have for fortran compilers.  As far as packages that
need fortran, we have (package name plus excerpts from the package
Makefile):

devel/netcdf:
    .if ! exists(/usr/bin/fort77)
    DEPENDS+=       fort77-1.14a:../../lang/fort77
    .endif

  checks for forts="xlf fort77 ghf77 f77 cf77 g77 xlf90 f90"
  with configure


math/xmgr
   .if ! exists(/usr/bin/fort77)
   DEPENDS+=       fort77-1.14a:../../lang/fort77
   .endif

   checks for "f77 fort77 g77 f90 f95" with configure

math/R
   .if !exists(/usr/bin/f77)
   DEPENDS+=       f2c-19980913:../../lang/f2c
   .endif

   from 'INSTALL':
   To compile R, you need a FORTRAN compiler or f2c, the FORTRAN-to-C
   converter.  The default is to search for f77, g77, fort77, f90, xlf,
   cf77, and fc (in that order), and then for f2c, and use whichever is
   found first; if none is found, R cannot be compiled.  The search
   mechanism can be changed using the `--with-g77', `--with-f77', and
   `--with-f2c' command line options to configure.  If your FORTRAN
   compiler is in a non-standard location, you should set the enviroment
   variable PATH accordingly before running configure.

math/fftw
   no checks in pkgsrc Makefile, but 'configure' does check for fortran:
   if fortran ("f77 xlf77 cf77 g77 fort77 f90 xlf90") is not found it 
   adds the --disable-fortran flag and doesn't build the fortran
   interface.  Means that 1.3.x machines with lang/fort77 installed will
   pick up fortran but the dependency won't be registered.

math/scilab
   .if !exists(/usr/bin/fort77)
   DEPENDS+=       f2c-19980913:../../lang/f2c
   .endif

   the configure script looks for 'f77' and then 'f2c-f77'


./parallel/mpi-ch/

fortran interface is disabled:

CONFIGURE_ARGS+=     -nof77 -make=${GMAKE} -mpe -rsh=ssh -opt=-O -nodevdebug


./parallel/pvm3/


  .if exists(/usr/bin/f77)
  F77=                    /usr/bin/f77
  .else
  F77=                    f2c-f77
  BUILD_DEPENDS+=         f2c-f77:../../lang/f2c
  .endif
  MAKE_FLAGS+=            F77=${F77}


I think this is it for packages which use fortran.  The summary is:
we (mostly) look for '/usr/bin/fort77' to add the fort77 dependency and
most packages which use fortran look for 'fort77' as part of the configure
script.

Now the question is what (if anything) to do before the egcs fortran is
fixed.  For me, I need at least one of these packages to work now, so I
hacked it a little to use 'f2c-f77' as the fortran compiler on my machine.
An even uglier hack is 
mv /usr/bin/fort77 /usr/bin/fort77.broken
ln -s /usr/pkg/bin/f2c-f77 /usr/bin/fort77
which is maybe ok on my machine for a workaround, but not ok for anything
else.

long term, g77 should be fixed, but my guess is thats probably a longer
term project plus I don't know how much effort the egcs people want to put
on fortran since c and c++ are _much_ more popular.

Any suggestions on how we should handle this before then?  Nothing jumps
out at me except several ugly hacks which I don't want to introduce.


as far as egcs fortran being broken, I've seen the following issues:

  pmax:  can't even build 'hello world'.  (see pr 8574)

  sparc: math/scilab package crashes during some of the tests.  compiling
         with  -g shows crash happens in some fortran code. 

  mac68k: math/scilab package fails some of its self tests.  In particular
        there are some errors in sparse matrix manipulations


f2c-f77 works fine in these 3 cases.

-Dan