Re: [HACKERS] 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
pgman wrote: 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. Let me also add that on my old dual P3 550 256MB RAM -g significantly slowed down the build because linking took a long time, probably because it had to read in all those debug symbols for the link --- I remember the backend link taking quite a lot of time. In fact, even though I was debugging the backend regularly, I removed -g and added it only when I wanted to debug. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: pgman wrote: 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. Let me also add that on my old dual P3 550 256MB RAM -g significantly slowed down the build because linking took a long time, probably because it had to read in all those debug symbols for the link --- I remember the backend link taking quite a lot of time. In fact, even though I was debugging the backend regularly, I removed -g and added it only when I wanted to debug. It did somethimes in the past proove to be good luck to have symbols in a core file accidentially. If you want to find them in an arbitrary out of the box installation, they have to be in the default configuration. That they cannot be there if a non-gcc does not optimize the code then, sure. But I don't really see the confusion you're talking about. Nor do I see the importance of link-time when setting up a production system from sources. Do not mix up developer usage with DBA usage. You can ask a developer to use --disable-debug, and when he complains about slow compiles it's still time to tell him. But if you expect a DBA to configure --enable-debug you will get core files that are plain useless and it's too late. What I would like to maintain is the best possible support capability (finding symbols wherever possible to do the aftermath of a crashed backend), while providing the best possible performance - with performance having priority. That this leads to different options used on different platforms and compilers, so be it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: Jan Wieck wrote: In fact, even though I was debugging the backend regularly, I removed -g and added it only when I wanted to debug. It did somethimes in the past proove to be good luck to have symbols in a core file accidentially. If you want to find them in an arbitrary out of the box installation, they have to be in the default configuration. That they cannot be there if a non-gcc does not optimize the code then, sure. But I don't really see the confusion you're talking about. Nor do I see the importance of link-time when setting up a production system from sources. Do not mix up developer usage with DBA usage. You can ask a developer to use --disable-debug, and when he complains about slow compiles it's still time to tell him. But if you expect a DBA to configure --enable-debug you will get core files that are plain useless and it's too late. What I would like to maintain is the best possible support capability (finding symbols wherever possible to do the aftermath of a crashed backend), while providing the best possible performance - with performance having priority. That this leads to different options used on different platforms and compilers, so be it. This leaves us with --enable-debug for non-gcc compilers, and adding --disable-debug for gcc compilers. Right now configure --help has: --enable-debug build with debugging symbols (-g) If people want to add --disable-debug, and document which is gcc and non-gcc, that is fine with me. Also, usually, you don't want to run the debugger on optimized code unless you are debugging a compiler issue, so maybe we should call it --debugging-symbols and --no-debugging-symbols to make it clear what the option does. I never want to run any debugger, I am sometimes forced to do so and then the more symbols I have the better. Debugging optimized code can lead to some confusion as the optimizer is allowed to reorder code execution or keep variables in registers instead of on the stack and thus, the flow of instructions is not in sync with the sourcecode, what makes it kinda hard sometimes to set breakpoints or to see what statements actually have NOT been executed already when looking at a file. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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? [EMAIL PROTECTED]:~/tmp$ gcc -c foo.c [EMAIL PROTECTED]:~/tmp$ ls -l foo.o -rw-r--r--1 kevinkevin 876 Oct 26 18:52 foo.o [EMAIL PROTECTED]:~/tmp$ gcc -g -c foo.c [EMAIL PROTECTED]:~/tmp$ ls -l foo.o -rw-r--r--1 kevinkevin 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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
Re: [HACKERS] 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? [EMAIL PROTECTED]:~/tmp$ gcc -c foo.c [EMAIL PROTECTED]:~/tmp$ ls -l foo.o -rw-r--r--1 kevinkevin 876 Oct 26 18:52 foo.o [EMAIL PROTECTED]:~/tmp$ gcc -g -c foo.c [EMAIL PROTECTED]:~/tmp$ ls -l foo.o -rw-r--r--1 kevinkevin 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 [EMAIL PROTECTED] | (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
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Greg Stark [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote: Greg Stark [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian [EMAIL PROTECTED] 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 ---(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
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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
[HACKERS] Still a few flaws in configure's default CFLAGS selection
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
Re: [HACKERS] 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 [EMAIL PROTECTED] | (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://archives.postgresql.org
