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

From Bruce Momjian
Subject Re: Still a few flaws in configure's default CFLAGS selection
Date
Msg-id 200310270304.h9R34BN14450@candle.pha.pa.us
Whole thread Raw
In response to Re: Still a few flaws in configure's default CFLAGS selection  (Kevin Brown <kevin@sysexperts.com>)
Responses Re: Still a few flaws in configure's default CFLAGS selection
List pgsql-hackers
Kevin Brown wrote:
> > > You do realize that as of now, -g is the default for gcc?
> 
> It is?
> 
> kevin@filer:~/tmp$ gcc -c foo.c
> kevin@filer:~/tmp$ ls -l foo.o
> -rw-r--r--    1 kevin    kevin         876 Oct 26 18:52 foo.o
> kevin@filer:~/tmp$ gcc -g -c foo.c
> kevin@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-debugif 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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Still a few flaws in configure's default CFLAGS selection
Next
From: Bruce Momjian
Date:
Subject: Re: BEGIN vs START TRANSACTION