Re: Still a few flaws in configure's default CFLAGS selection
От | Bruce Momjian |
---|---|
Тема | Re: Still a few flaws in configure's default CFLAGS selection |
Дата | |
Msg-id | 200310241401.h9OE14f16062@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Still a few flaws in configure's default CFLAGS (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Still a few flaws in configure's default CFLAGS selection
Re: Still a few flaws in configure's default CFLAGS selection |
Список | pgsql-hackers |
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, Pennsylvania19073
В списке pgsql-hackers по дате отправления: