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 | 200310270304.h9R34BN14450@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Still a few flaws in configure's default CFLAGS selection (Kevin Brown <kevin@sysexperts.com>) |
Ответы |
Re: Still a few flaws in configure's default CFLAGS selection
(Kevin Brown <kevin@sysexperts.com>)
|
Список | pgsql-hackers |
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-debugif 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, Pennsylvania19073
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: Still a few flaws in configure's default CFLAGS selection