Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!ais.net!uunet!in2.uu.net!128.138.240.25!boulder!rintintin.Colorado.EDU!fcrary
From: fcrary@rintintin.Colorado.EDU (Frank Crary)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Fortran on FreeBSD
Date: 4 Apr 1997 01:47:18 GMT
Organization: University of Colorado, Boulder
Lines: 66
Message-ID: <5i1mj6$b7c@lace.colorado.edu>
References: <5hrd3n$58n@lace.colorado.edu> <5hrkn1$sib@nntp1.u.washington.edu>
NNTP-Posting-Host: rintintin.colorado.edu
NNTP-Posting-User: fcrary
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38376
In article <5hrkn1$sib@nntp1.u.washington.edu>,
Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>> Does anyone know where I can find a good fortran compiler for FreBSD
>> (v. 2.1.5 if that matters)? g77 seems to object to some variable
>> declarations and uses of the save command. Using f2c to convert
>> to c isn't as useful to me, since it would require rewriting the make
>> files,
>I don't understand your statement about rewriting the Makefiles. There
>is a wrapper called f77 that encapsulates the calls to f2c and gcc to
>compile fortran.
Thanks, that's nice to know. I managed to miss that fact.
>> and even so, I'm hitting the known bug reported in the man
>> page...
>You know the function, and the location(s) from where the function is called.
>It seems fairly easy to fix.
Sure, but just finding a fortran compiler would be easier, so I thought
it couldn't hurt to ask.
>> (Please don't give me grief about asking for a "good fortran compiler":
>> I know that's a contradiction, and I wish the code were in c. But
>> I'm trying to install a package someone else wrote, and I don't feel
>> like rewriting 2.6 meg of code in c.)
>I don't understand this statement. One should use the best tool
>to solve the problem. For straight number crunching, Fortran is
>probably the best choice. If this 2.6 meg of code contains computations
>using complex number, Fortran is perhaps a more nature choice of
>language than C.
It doesn't use any complex numbers (in fact most of the run time is
spent calculating square roots) and I disagree about fortran being
better for straight number crunching. In terms of run times, I
generally get better results from C code (which may or may not
be a result of the quality of the optimizers on the compilers I
have used.) I agree about using the best tool for the problem,
which was the whole point of my remark. In this case, the main
requirements are portability and speed, although the use of inputs
from the command line would be nice. In all of those regards,
c has an advantage over fortran. The code was written in fortran
simply because many scientists simply use fortran by default,
whether or not it's appropriate for the problem. Since I'm stuck
with the code as written, that a moot point, but it's one of
my long-standing complaints about scientific programming.
>> PS: There is a minor bug in the 2.1.5 distribution of g77. It
>> uses something called "f771", which the 2.1.5 installation software
>> puts in /usr/local/libexec. g77 can't find it there, and the easiest
>> solution I've found is to put a symbolic link in /usr/local/bin.
>PS: If you have a version of g77 from 0.5.16 through 0.5.19, you have
>other problems to worry about than the location of f771...
Obviously. Since I already have a patch to deal with this, it's not
a problem at all, and installing a new version of g77 would inherently
be more of a problem. I mentioned it for two reasons. First, to save
anyone else who encountered the problem a little time in fixing it,
and, second, in the hopes that it would be corrected in later distributions
(if it hasn't been already corrected.)
Frank Crary
CU Boulder