Re: Still a few flaws in configure's default CFLAGS selection

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Still a few flaws in configure's default CFLAGS selection
Дата
Msg-id 874qy9bvsm.fsf@stark.dyndns.tv
обсуждение исходный текст
Ответ на Still a few flaws in configure's default CFLAGS selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Still a few flaws in configure's default CFLAGS selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> 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?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Some thoughts about i/o priorities and throttling vacuum
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: pg_autovacuum and VACUUM FREEZE