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

Bruce Momjian wrote:
> 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?

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

If -g is the default, it must be very recent, in which case it's
obviously not something for our configuration scripts to rely on.

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

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.

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.

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

--
Kevin Brown kevin(at)sysexperts(dot)com