While fooling with adding -fno-strict-aliasing to configure, I realized
that there are still some oddities about its selection of CFLAGS.  The
problems stem from the fact that autoconf will always select a default
value of CFLAGS that includes "-g", if the compiler accepts "-g" at all.
This has a couple of consequences:

1. --enable-debug is nearly useless, since unless you've manually
specified CFLAGS, what you're going to get will include -g anyway.

2. The code Bruce put in to default to "-O" on non-gcc compilers
will never actually fire.

It would be fairly easy to override autoconf's behavior, but I wonder
whether that will surprise people who are used to the "standard"
behavior of autoconf scripts.  Personally I've always felt that
defaulting to -g was a bizarre and unwise choice on the part of the
autoconf developers, but maybe someone out there wants to defend it?

Comments anyone?

			regards, tom lane

Wed, 15 Oct 2003 18:49:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote:
> While fooling with adding -fno-strict-aliasing to configure, I realized
> that there are still some oddities about its selection of CFLAGS.  The
> problems stem from the fact that autoconf will always select a default
> value of CFLAGS that includes "-g", if the compiler accepts "-g" at all.
> This has a couple of consequences:
> 
> 1. --enable-debug is nearly useless, since unless you've manually
> specified CFLAGS, what you're going to get will include -g anyway.
> 
> 2. The code Bruce put in to default to "-O" on non-gcc compilers
> will never actually fire.

I see that now. I saw in configure:
	
	if test "$ac_test_CFLAGS" = set; then
	  CFLAGS=$ac_save_CFLAGS
	elif test $ac_cv_prog_cc_g = yes; then
	  if test "$GCC" = yes; then
	    CFLAGS="-g -O2"
	  else
	    CFLAGS="-g"
	  fi
	else
	  if test "$GCC" = yes; then
	    CFLAGS="-O2"
	  else
	    CFLAGS=
	  fi
	fi

and assumed the CFLAGS= line was the default, and thought the
$ac_cv_prog_cc_g = yes test was for debug enabled.  Now I see it just
checks if -g works and uses it unconditionally.  That is bizarre.  I
was never even fond of configure defaulting to -O2.  It is a fine
default, but the CFLAGS default should be our decision, not configure.

> It would be fairly easy to override autoconf's behavior, but I wonder
> whether that will surprise people who are used to the "standard"
> behavior of autoconf scripts.  Personally I've always felt that
> defaulting to -g was a bizarre and unwise choice on the part of the
> autoconf developers, but maybe someone out there wants to defend it?

Agreed.  What does autoconf know about our project?  Nothing.  We should
not default to their compile flages.

-- 
  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, Pennsylvania 19073

Wed, 15 Oct 2003 21:22:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection

Tom Lane <tgl@sss.pgh.pa.us> writes:

> It would be fairly easy to override autoconf's behavior, but I wonder
> whether that will surprise people who are used to the "standard"
> behavior of autoconf scripts.  Personally I've always felt that
> defaulting to -g was a bizarre and unwise choice on the part of the
> autoconf developers, but maybe someone out there wants to defend it?

uh, since you asked. I think the logic is that, at least with gcc, -g is never
harmful since you can compile with -O and -g and then strip later if
necessary. Does it still default to -g with compilers that cannot do -O and -g
together?


Also, RMS happens to think all binaries should be installed with symbols. I
think he's seen far too many emacs bug reports where the user was unable to
provide any useful bug report because the binary was stripped. The space
needed is usually (but not always) fairly minimal anyways. 

Personally I tend to agree with this. It always annoys me that the first thing
I have to do when I try to track down a bug is download the source and
recompile the program.

But I don't think that's the logic behind the autoconf defaults, only a bit of
useful context.

-- 
greg


16 Oct 2003 01:23:21 -0400
Greg Stark <gsstark@mit.edu>
Re: Still a few flaws in configure's default CFLAGS selection
Greg Stark <gsstark@mit.edu> writes:
> uh, since you asked. I think the logic is that, at least with gcc, -g
> is never harmful since you can compile with -O and -g and then strip
> later if necessary.

Yeah, but ...

> Does it still default to -g with compilers that
> cannot do -O and -g together?

*Yes*.  This is exactly the problem, really.  One could reasonably
accuse the autoconf developers of FSF imperialism, because they have
seen to it that autoconf-based configure scripts will choose non-optimal
CFLAGS for non-gcc compilers.  These same geeks would be screaming for
Microsoft's blood if Microsoft tried comparable tactics, so I don't have
a whole lot of sympathy.

(Side note: I've been overriding this particular autoconf-ism in
libjpeg's configure script since about 1995, so it's not like my
antipathy to it is a new subject.)

> Also, RMS happens to think all binaries should be installed with symbols. I
> think he's seen far too many emacs bug reports where the user was unable to
> provide any useful bug report because the binary was stripped.

I hear where he's coming from, believe me.  But RPM builds generally strip
the binaries anyway, so autoconf isn't really accomplishing anything
with this that I can see.  The mass market won't be providing stack
traces with their bug reports, whether the binary has symbols or not.

			regards, tom lane

Thu, 16 Oct 2003 01:59:48 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection 
Tom Lane writes:

> *Yes*.  This is exactly the problem, really.  One could reasonably
> accuse the autoconf developers of FSF imperialism, because they have
> seen to it that autoconf-based configure scripts will choose non-optimal
> CFLAGS for non-gcc compilers.  These same geeks would be screaming for
> Microsoft's blood if Microsoft tried comparable tactics, so I don't have
> a whole lot of sympathy.

The philosophy of the autotools is to give power to the experienced user
(you can set your own CFLAGS) and to give portable defaults to everyone
else (-O is technically not portable).  Another contributing factor is
that the default stems from a different era, one might say, and has been
the same for a long time, and changing it now would probably upset as many
people as it would please.

In other news, if you don't like what autoconf does and you are confident
about what your compiler can handle, you are free to set up a
config.status file or set CFLAGS in your environment.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 16 Oct 2003 09:45:44 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Still a few flaws in configure's default CFLAGS
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> [ griping about autoconf's default choices for CFLAGS ]

> The philosophy of the autotools is to give power to the experienced user
> (you can set your own CFLAGS) and to give portable defaults to everyone
> else (-O is technically not portable).

It'd be nicer if they had tried to give *useful* defaults to everyone else.
The existing behavior is reasonable for people testing beta-quality
software, but it's not a helpful choice for production code.  It's great
that someone who knows what they're doing can override it, but right now
I'm concerned with the default build behavior for people who don't know.

> Another contributing factor is
> that the default stems from a different era, one might say, and has been
> the same for a long time, and changing it now would probably upset as many
> people as it would please.

FWIW, I've been overriding the default CFLAGS to be -O for non-gcc in
libjpeg's configure script since [...digs...] release 6b of March 1998.
I've yet to hear any complaint about it, and that code is used on a much
wider variety of systems than Postgres runs on.  So my opinion is that
-O is perfectly portable and unlikely to upset anyone for production
code --- especially when configure advertises a switch to select -g
instead.

			regards, tom lane

Thu, 16 Oct 2003 10:28:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Still a few flaws in configure's default CFLAGS 
Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > uh, since you asked. I think the logic is that, at least with gcc, -g
> > is never harmful since you can compile with -O and -g and then strip
> > later if necessary.
> 
> Yeah, but ...
> 
> > Does it still default to -g with compilers that
> > cannot do -O and -g together?
> 
> *Yes*.  This is exactly the problem, really.  One could reasonably
> accuse the autoconf developers of FSF imperialism, because they have
> seen to it that autoconf-based configure scripts will choose non-optimal
> CFLAGS for non-gcc compilers.  These same geeks would be screaming for
> Microsoft's blood if Microsoft tried comparable tactics, so I don't have
> a whole lot of sympathy.
> 
> (Side note: I've been overriding this particular autoconf-ism in
> libjpeg's configure script since about 1995, so it's not like my
> antipathy to it is a new subject.)
> 
> > Also, RMS happens to think all binaries should be installed with symbols. I
> > think he's seen far too many emacs bug reports where the user was unable to
> > provide any useful bug report because the binary was stripped.
> 
> I hear where he's coming from, believe me.  But RPM builds generally strip
> the binaries anyway, so autoconf isn't really accomplishing anything
> with this that I can see.  The mass market won't be providing stack
> traces with their bug reports, whether the binary has symbols or not.

Also, -g is not the opposite of strip.  A default compile adds function
name symbols.  -g adds debug symbols, strip removes all symbols, so a
compile that uses -g and strip has fewer symbols than one that does a
compile without -g and without strip.

Also, I thought Peter advocated adding -g a few releases back.  I didn't
agree, but I lost the vote, so I thought it was done.  Were we
supresssing -g in older releases?  Peter?

-- 
  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, Pennsylvania 19073

Thu, 16 Oct 2003 13:47:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, I thought Peter advocated adding -g a few releases back.  I didn't
> agree, but I lost the vote, so I thought it was done.  Were we
> supresssing -g in older releases?  Peter?

I don't recall any such vote.  Had we done that, we'd have removed
--enable-debug, I'd think.

			regards, tom lane

Thu, 16 Oct 2003 13:56:10 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Also, I thought Peter advocated adding -g a few releases back.  I didn't
> > agree, but I lost the vote, so I thought it was done.  Were we
> > supresssing -g in older releases?  Peter?
> 
> I don't recall any such vote.  Had we done that, we'd have removed
> --enable-debug, I'd think.

The vote was whether -g should be used for a default compile.  Of course
--enable-debug would continue using -g.  Maybe we kept --enable-debug
for backward compatibility or to force -g if you modified CFLAGS?

-- 
  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, Pennsylvania 19073

Thu, 16 Oct 2003 14:02:03 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The vote was whether -g should be used for a default compile.  Of course
> --enable-debug would continue using -g.  Maybe we kept --enable-debug
> for backward compatibility or to force -g if you modified CFLAGS?

I can't see why we would have kept --enable-debug if we intended to make
-g be default anyway.  Backwards compatibility is not an issue, because
configure simply ignores --enable switches it doesn't recognize (another
questionable autoconf design decision, but I digress).  And if you are
setting CFLAGS for yourself, you are surely capable of adding -g to it
if you want; why would you type seven times as much to accomplish the
same thing?

			regards, tom lane

Thu, 16 Oct 2003 14:18:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection 
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Also, I thought Peter advocated adding -g a few releases back.  I didn't
> > > agree, but I lost the vote, so I thought it was done.  Were we
> > > supresssing -g in older releases?  Peter?
> > 
> > I don't recall any such vote.  Had we done that, we'd have removed
> > --enable-debug, I'd think.
> 
> The vote was whether -g should be used for a default compile.  Of course
> --enable-debug would continue using -g.  Maybe we kept --enable-debug
> for backward compatibility or to force -g if you modified CFLAGS?

Here is the thread discussing the -g flag:

	http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php

-- 
  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, Pennsylvania 19073

Thu, 16 Oct 2003 14:52:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The vote was whether -g should be used for a default compile.  Of course
> > --enable-debug would continue using -g.  Maybe we kept --enable-debug
> > for backward compatibility or to force -g if you modified CFLAGS?
> 
> I can't see why we would have kept --enable-debug if we intended to make
> -g be default anyway.  Backwards compatibility is not an issue, because
> configure simply ignores --enable switches it doesn't recognize (another
> questionable autoconf design decision, but I digress).  And if you are
> setting CFLAGS for yourself, you are surely capable of adding -g to it
> if you want; why would you type seven times as much to accomplish the
> same thing?

The discussion mentions the problem with keeping --enable-debug:

	http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php

I am not sure that Peter actually implemented it, but when I started
seeing -g flags in the compile, I assumed it had been done.

-- 
  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, Pennsylvania 19073

Thu, 16 Oct 2003 14:54:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Tom Lane wrote:
>>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>> Also, I thought Peter advocated adding -g a few releases back.

>> I don't recall any such vote.

> The vote was whether -g should be used for a default compile.

> Here is the thread discussing the -g flag:
> 	http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php

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.

			regards, tom lane

Fri, 17 Oct 2003 02:13:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection 
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?

-- 
Peter Eisentraut   peter_e@gmx.net


Fri, 24 Oct 2003 14:47:17 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Still a few flaws in configure's default CFLAGS
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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 24 Oct 2003 10:01:04 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
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?  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?


Jan

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


Sun, 26 Oct 2003 19:09:19 -0500
Jan Wieck <JanWieck@Yahoo.com>
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@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...

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@sysexperts.com

Sun, 26 Oct 2003 18:53:39 -0800
Kevin Brown <kevin@sysexperts.com>
Re: Still a few flaws in configure's default CFLAGS selection
Jan Wieck wrote:
> 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?  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.

-- 
  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, Pennsylvania 19073

Sun, 26 Oct 2003 21:59:04 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
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@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-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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 26 Oct 2003 22:04:11 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote:

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

But doesn't --enable-debug turn off optimization?

It's really a question of what the default behavior should be for each
option.  Clearly for non-gcc compilers, the default should be -O only
since they probably can't simultaneously handle -g.  But gcc builds are
an exception, one which I think is worth considering.  Hence my opinion
that for gcc builds, the default should be -g and -O.


-- 
Kevin Brown					      kevin@sysexperts.com

Mon, 27 Oct 2003 00:23:46 -0800
Kevin Brown <kevin@sysexperts.com>
Re: Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote:
> Jan Wieck wrote:
>> 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?  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.

The other compiler flags like -O are much more important because the out 
of the box configuration is the one we're allways blamed for. If it's 
too hard to teach autoconf the difference between gcc and non-gcc, then 
rip 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 #


Mon, 27 Oct 2003 08:45:20 -0500
Jan Wieck <JanWieck@Yahoo.com>
Re: Still a few flaws in configure's default CFLAGS selection
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.

> The other compiler flags like -O are much more important because the out 
> of the box configuration is the one we're allways blamed for. If it's 
> too hard to teach autoconf the difference between gcc and non-gcc, then 
> rip it.

Sure, we can do it, but it is a question of consistency.

-- 
  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, Pennsylvania 19073

Mon, 27 Oct 2003 10:31:59 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection