| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Still a few flaws in configure's default CFLAGS selection | 
| Date: | 2003-10-16 05:59:48 | 
| Message-ID: | 16886.1066283988@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Greg Stark <gsstark(at)mit(dot)edu> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen | 2003-10-16 06:01:13 | Re: Some thoughts about i/o priorities and throttling vacuum | 
| Previous Message | Manfred Spraul | 2003-10-16 05:51:49 | Re: Database Kernels and O_DIRECT |