Re: Still a few flaws in configure's default CFLAGS selection

Bruce Momjian wrote:

> pgman wrote:
>> Jan Wieck wrote:
>> > >> >> > What Peter was advocating in that thread was that we enable -g by
>> > >> >> > default *when building with gcc*.  I have no problem with that, since
>> > >> >> > there is (allegedly) no performance penalty for -g with gcc.  However,
>> > >> >> > the actual present behavior of our configure script is to default to -g
>> > >> >> > for every compiler, and I think that that is a big mistake.  On most
>> > >> >> > non-gcc compilers, -g disables optimizations, which is way too high a
>> > >> >> > price to pay for production use.
>> > >> >> 
>> > >> >> You do realize that as of now, -g is the default for gcc?  Was that the
>> > >> >> intent?
>> > >> > 
>> > >> > I was going to ask that myself.  It seems strange to include -g by default ---
>> > >> > we have --enable-debug, and that should control -g on all platforms.
>> > >> 
>> > >> Could it be that there ought to be a difference between the defaults of 
>> > >> a devel CVS tree, a BETA tarball and a final "production" release?
>> > > 
>> > > I am afraid that adds too much confusion to the debug situation.  We
>> > > have a flag to do -g;  let people use it if they want it.
>> > > 
>> > 
>> > Well, -g eats up some disk space, but for a gcc it doesn't need CPU 
>> > cycles or anything else. I doubt many people who pay the horrible 
>> > storage capacity overhead for PostgreSQL are that concerned about some 
>> > extra symbols stored with their binaries, but let's not argue about that 
>> > one.
>> 
>> Well, people are stripping the executable, so some of them must care. 
>> In fact, if we enable -g by default for gcc, how do compile with default
>> symbols?  We would need another configure option.  Strip is not the same
>> as default symbols.
> 
> Let me also add that on my old dual P3 550 256MB RAM -g significantly
> slowed down the build because linking took a long time, probably because
> it had to read in all those debug symbols for the link --- I remember
> the backend link taking quite a lot of time.
> 
> In fact, even though I was debugging the backend regularly, I removed -g
> and added it only when I wanted to debug.
> 

It did somethimes in the past proove to be good luck to have symbols in 
a core file accidentially. If you want to find them in an arbitrary out 
of the box installation, they have to be in the default configuration. 
That they cannot be there if a non-gcc does not optimize the code then, 
sure. But I don't really see the confusion you're talking about. Nor do 
I see the importance of link-time when setting up a production system 
from sources. Do not mix up developer usage with DBA usage. You can ask 
a developer to use "--disable-debug", and when he complains about slow 
compiles it's still time to tell him. But if you expect a DBA to 
configure "--enable-debug" you will get core files that are plain 
useless and it's too late.

What I would like to maintain is the best possible support capability 
(finding symbols wherever possible to do the aftermath of a crashed 
backend), while providing the best possible performance - with 
performance having priority. That this leads to different options used 
on different platforms and compilers, so be it.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #