Still a few flaws in configure's default CFLAGS selection

Still a few flaws in configure's default CFLAGS selection

Post by tgl » Fri, 17 Oct 2003 07:49:41


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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by pgma » Fri, 17 Oct 2003 10:22:43


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.


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

--
Bruce Momjian | http://www.yqcomputer.com/
XXXX@XXXXX.COM | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.yqcomputer.com/

 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by gsstar » Fri, 17 Oct 2003 14:23:21


Tom Lane < XXXX@XXXXX.COM > 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. 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


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by tgl » Fri, 17 Oct 2003 14:59:48

Greg Stark < XXXX@XXXXX.COM > writes:

Yeah, but ...


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


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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to XXXX@XXXXX.COM so that your
message can get through to the mailing list cleanly
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by pgma » Sat, 18 Oct 2003 02:47:10


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://www.yqcomputer.com/
XXXX@XXXXX.COM | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by tgl » Sat, 18 Oct 2003 02:56:10

Bruce Momjian < XXXX@XXXXX.COM > writes:

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

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by pgma » Sat, 18 Oct 2003 03:02:03


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://www.yqcomputer.com/
XXXX@XXXXX.COM | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.yqcomputer.com/
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by tgl » Sat, 18 Oct 2003 03:18:27

Bruce Momjian < XXXX@XXXXX.COM > writes:

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by pgma » Sat, 18 Oct 2003 03:52:55


Here is the thread discussing the -g flag:

http://www.yqcomputer.com/

--
Bruce Momjian | http://www.yqcomputer.com/
XXXX@XXXXX.COM | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by pgma » Sat, 18 Oct 2003 03:54:06


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

http://www.yqcomputer.com/

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://www.yqcomputer.com/
XXXX@XXXXX.COM | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.yqcomputer.com/
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by tgl » Sat, 18 Oct 2003 15:13:37

Bruce Momjian < XXXX@XXXXX.COM > 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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by pgma » Sat, 25 Oct 2003 23:01:04


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://www.yqcomputer.com/
XXXX@XXXXX.COM | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by JanWiec » Tue, 28 Oct 2003 09:09:19


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. #
#================================================== XXXX@XXXXX.COM #


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to XXXX@XXXXX.COM )
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by kevi » Tue, 28 Oct 2003 11:53:39


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.


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.


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 XXXX@XXXXX.COM

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
 
 
 

Still a few flaws in configure's default CFLAGS selection

Post by pgma » Tue, 28 Oct 2003 11:59:04


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://www.yqcomputer.com/
XXXX@XXXXX.COM | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings