In article <mcampbel.719931163@eola.cs.ucf.edu>, mcampbel@cs.ucf.edu (Mike Campbell ) writes:
|> Conrad_Nobili@Harvard.EDU (Conrad C. Nobili) writes:
|> 
|> >In article <1992Oct23.122551.11874@athena.mit.edu>,
|> >hellmund@hep.physik.uni-leipzig.dbp.de wrote:
|> 
|> >> Now my question: Is that an error of my installation/machine
|> >> or has really nobody before tested the f2c binary in the SLS 
|> >> package? 
|> 
|> >Well, I too tested it on some pretty simple programs and found it crashed
|> >every time.  I am sucking down the sources now so as to check out what you
|> >mentioned in your post....  Thanks for the knowledge that it can be made to
|> >work and the pointer to the source....
|> 
|> I've seen the same behavior.  Let us all know when/if anything gets discovered.
|> 

I mailed a reply to the original poster, but hopefully a followup post will be
useful...

If you compile f2c "out of the box," the default behavior is to compile and 
link an included routine malloc.c, which contains memory handling routines that
are faster than those in many standard C libraries.  Since Linux uses GNU C,
however, these (or similar) faster routines are already part of the standard 
lib, you don't need malloc.c; and in fact, the program crashes if you compile
it this way.

An easy solution is to recompile from source, changing one line in the 
makefile:

change the macro OBJECTS from

OBJECTS = $(OBJECTSd) malloc.o

to

OBJECTS = $(OBJECTSd) #malloc.o

This way, the unneeded routine will not be included.

Hope this helps,

Bryson Lee
blee@halon.dfrf.nasa.gov

PS.  If anyone is interested, once I get a new binary compiled for 0.98, I'll
post it to tsx-11.  Mail to let me know.