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

Kevin Brown wrote:
> > > You do realize that as of now, -g is the default for gcc?
>
> It is?
>
> kevin(at)filer:~/tmp$ gcc -c foo.c
> kevin(at)filer:~/tmp$ ls -l foo.o
> -rw-r--r-- 1 kevin kevin 876 Oct 26 18:52 foo.o
> kevin(at)filer:~/tmp$ gcc -g -c foo.c
> kevin(at)filer:~/tmp$ ls -l foo.o
> -rw-r--r-- 1 kevin kevin 12984 Oct 26 18:52 foo.o
> Reading specs from /usr/lib/gcc-lib/i386-linux/3.3/specs
>
>
> Doesn't look like it to me...

He meant for compiling PostgreSQL using gcc, -g is the default, or was
until we changed it yesterday. We can't use -g for non-gcc compilers
because it often turns off optimization.

> > 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.
>
> I thought --enable-debug had other implications, e.g. enabling assert()s
> and other such things you might want enabled for debugging but not for
> production. It certainly makes sense for it to have such semantics even
> if it doesn't right now.

We have --enable-cassert for asserts. Right now I only see:

# supply -g if --enable-debug
if test "$enable_debug" = yes -a "$ac_cv_prog_cc_g" = yes; then
CFLAGS="$CFLAGS -g"
fi

> When combined with gcc, -g is, IMO, too useful to eliminate: it makes it
> possible to get good stacktraces in the face of crashes, and makes it
> possible to examine variables and such when looking at core files.

If folks want it, they can enable it, and you still get function call
names in a backtrace without -g, just not the line numbers.

> > 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.
>
> This should be up to the individual. I'd argue that disk space is so
> plentiful and so cheap these days that executable bloat is hardly worth
> considering.
>
> But even if it were, a database tends to be so critical to so many
> things that you probably want to know why and how it crashes more than
> you would most other things. So even if you might be inclined to strip
> most of your binaries, you might think twice about doing the same for
> the PG binaries.

Well, we don't want to use debug for non-gcc (no optimization) so do we
do -g for gcc, and then --enable-debug does nothing. Seems people can
decide for themselves.

--
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