Date:	Thu, 4 Nov 1999 10:10:26 +0200 (WET)
From:	Andris Pavenis <pavenis AT ieva01 DOT lanet DOT lv>
To:	Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: -g vs -s
In-Reply-To:	<199911030849.JAA11948@propus.lu.erisoft.se>
Message-ID:	<Pine.A41.4.05.9911040955430.85860-100000@ieva01.lanet.lv>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 3 Nov 1999, Martin Stromberg wrote:

> > 
> > On 2 Nov 99, at 15:48, Eli Zaretskii wrote:
> > 
> > > 
> > > On Tue, 2 Nov 1999 pavenis AT lanet DOT lv wrote:
> > > 
> > > > Let's assume we have too files foo.c and bar.c in project. Rhide will 
> > > > generate commands like (if options -g and -O2 are requested in project)
> > > > 	gcc -g -O2 -c foo.c -o foo.o
> > > > 	gcc -g -O2 -c bar.c -o bar.o
> > > > 	gcc foo.o bar.o -o foo.exe
> > > 
> > > This can be handled by changing the relevant RHIDE_* macros so that it 
> > > passes -g or -g0 to the linker.
> > > 
> > > > We'll have similar problem also with many makefiles.
> > > 
> > > Most Makefile's I saw put -g into CFLAGS, so linking is done with -g as 
> > > well.
> > > 
> > 
> > Yes. Usualy we can find some workaround for problems some change 
> > causes. But I'm afraid this would require also novices to do such 
> > changes (messing with RHIDE-* macros, etc). If we remeber -lstdcx 
> > problem in rhide... . I'm afraid this would cause at least the same 
> > amount of questions as -lstdcxx/-lstdcx problem. Even if we update 
> > current versions to use -s by default, many poeple will still use 
> > outdated versions (and mix new ones and outdated ones) and will run 
> > into a trouble.
> > 
> > I think that the best is to avoid such hack
> 
> It's not a hack.
> 
> Anyway, how about telling RHIDE author about this if we decide to do
> this so he can add the switches _now_ (instead of when it's too
> late). I'm assuming here that adding the switches today wouldn't harm,
> would it?

I remember how meny questions followed after renaming libstdcx.a to
libstdcxx.a. I'm afraid that defaulting to use -s when no debug info is
requested will add at least one more MOST FREQUENTLY ASKED QUESTION:

	I built my project with rhide. Why rhide says that program 
 	don't have debug info?

We cannot expect that all users will synchronusly update also rhide so 
it's real that such question will be asked meny times.

Also none of systems I have used defaults to use -s when no -g* options
are used (Linux, AIX 4.3 on RS6000)

Now enough about why I don't want -s to be default by gcc when no
debugging info is requested. 


Perhaps it could be acceptable to default to -s in rhide when none of
debugging options are specified (to add -s to gcc command line when
building executable). At least so we are not going to break
anything. But one must have possibility to revert to old behaviour as not
all users will want that.

But it's not so easy as one can specify additional options for one
specified source file and additional compiler options for project
(debugging options may be hidden there). We must be sure that -s will be
used only if debugging info is not requested at all. So perhaps it is
still best to leave things as they are.

Andris

- Raw text -