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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Still a few flaws in configure's default CFLAGS selection
Date: 2003-10-24 14:01:04
Message-ID: 200310241401.h9OE14f16062@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> Tom Lane writes:
>
> > 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.

Also, -g bloats the executable, encouraging people/installers to run
strip, which removes all symbols. Without -g and without strip, at
least we get function names in the backtrace.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-10-24 14:08:33 Re: 7.4 compatibility question
Previous Message Alvaro Herrera 2003-10-24 13:25:42 Re: 7.4 compatibility question