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  (Jan Wieck <JanWieck@Yahoo.com>)
Re: Still a few flaws in configure's default CFLAGS selection  (Kevin Brown <kevin@sysexperts.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: 7.4 compatibility question
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: 7.4 compatibility question