From: drupp AT cs DOT washington DOT edu (Douglas Rupp)
Message-Id: <199607301736.KAA15461@june.cs.washington.edu>
Subject: Re: gcc -g -o
To: dj AT delorie DOT com (DJ Delorie)
Date: Tue, 30 Jul 1996 10:36:20 -0700 (PDT)
Cc: drupp AT cs DOT washington DOT edu, djgpp-workers AT delorie DOT com
In-Reply-To: <199607300117.VAA25632@delorie.com> from "DJ Delorie" at Jul 29, 96 09:17:17 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> 
> > How about making it do something useful, like w/o -g the .exe file will
> > be stripped and the coff file deleted after linking.
> 
> This would make djgpp operate differently than unix gcc, which does no
> such thing.  Besides, if you specify the .exe file as the output file,
> the coff file is already deleted.
> 

I not sure quite what you mean by "does no such thing", if you mean that
the unix gcc doesn't delete its coff file after linking then I suppose
you're right :-)

But seriously, some Unix ld's do allow/require -g in order to debug, which 
seems like the real issue here.

I believe the following is the current behavior?

gcc -o foo.exe
Deletes the coff file, leaves a bloated .exe
*Proposed new behavior: Deletes the coff file, strips the .exe

gcc -g -o foo.exe
Deletes the coff file, leaves a bloated .exe

gcc -o foo
Leaves a debuggable coff file, leaves a bloated .exe
*Proposed new behavior: Leaves a debuggable coff file, strips the .exe

gcc -g -o foo
Leaves a debuggable coff file, leaves a bloated .exe
----------------------------

1) All the former options are preserved
2) -g is made to do something useful on linking 
3) It can be argued that since some Unixes allow/require -g in order to
   do debugging that this is no unreasonable.
4) It silences all the whiners about huge executables.