Re: Still a few flaws in configure's default CFLAGS selection - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Still a few flaws in configure's default CFLAGS selection
Date
Msg-id 874qy9bvsm.fsf@stark.dyndns.tv
Whole thread Raw
In response to Still a few flaws in configure's default CFLAGS selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Still a few flaws in configure's default CFLAGS selection  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> It would be fairly easy to override autoconf's behavior, but I wonder
> whether that will surprise people who are used to the "standard"
> behavior of autoconf scripts.  Personally I've always felt that
> defaulting to -g was a bizarre and unwise choice on the part of the
> autoconf developers, but maybe someone out there wants to defend it?

uh, since you asked. I think the logic is that, at least with gcc, -g is never
harmful since you can compile with -O and -g and then strip later if
necessary. Does it still default to -g with compilers that cannot do -O and -g
together?


Also, RMS happens to think all binaries should be installed with symbols. I
think he's seen far too many emacs bug reports where the user was unable to
provide any useful bug report because the binary was stripped. The space
needed is usually (but not always) fairly minimal anyways. 

Personally I tend to agree with this. It always annoys me that the first thing
I have to do when I try to track down a bug is download the source and
recompile the program.

But I don't think that's the logic behind the autoconf defaults, only a bit of
useful context.

-- 
greg



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Some thoughts about i/o priorities and throttling vacuum
Next
From: Christopher Kings-Lynne
Date:
Subject: pg_autovacuum and VACUUM FREEZE