Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!stokes!ssr
From: ssr@stokes.Princeton.EDU (Steve S. Roy)
Newsgroups: comp.sys.next
Subject: Re: f2c and LARGE object files
Keywords: blech!
Message-ID: <8965@idunno.Princeton.EDU>
Date: 2 May 91 16:57:04 GMT
References: <1991May1.173124.17624@milton.u.washington.edu>
Sender: news@idunno.Princeton.EDU
Organization: Princeton University
Lines: 22

In article <1991May1.173124.17624@milton.u.washington.edu> dwatola@nextasy2 (David Watola) writes:
>
>has anyone noticed this problem with f2c:
>
>the resulting object file for my 40k source is a whopping 37 megs!!!  without
>the '-c' flag (and with a main() routine to link edit) this 37 meg file is
>still generated, but somehow gets trimmed down around 70k after link editing.


I don't think the problem is with f2c but rather with the assembler,
of all things.

I recently compiled a C program that used large staticly allocated
arrays and got a huge .o file that got trimmed down when linked.  A
little experimentation showed that the .s (assembly language) files
were fine but the size of the .o file was (roughly) proportional to
the size of the static arrays.

This is brain damage.  This should never happen.  It shows that
someone just wasn't thinking, and that no one is checking up on things.

Steve Roy