Jan Wieck wrote:
> > In fact, even though I was debugging the backend regularly, I removed -g
> > and added it only when I wanted to debug.
> >
>
> It did somethimes in the past proove to be good luck to have symbols in
> a core file accidentially. If you want to find them in an arbitrary out
> of the box installation, they have to be in the default configuration.
> That they cannot be there if a non-gcc does not optimize the code then,
> sure. But I don't really see the confusion you're talking about. Nor do
> I see the importance of link-time when setting up a production system
> from sources. Do not mix up developer usage with DBA usage. You can ask
> a developer to use "--disable-debug", and when he complains about slow
> compiles it's still time to tell him. But if you expect a DBA to
> configure "--enable-debug" you will get core files that are plain
> useless and it's too late.
>
> What I would like to maintain is the best possible support capability
> (finding symbols wherever possible to do the aftermath of a crashed
> backend), while providing the best possible performance - with
> performance having priority. That this leads to different options used
> on different platforms and compilers, so be it.
This leaves us with "--enable-debug" for non-gcc compilers, and adding
"--disable-debug" for gcc compilers.
Right now configure --help has:
--enable-debug build with debugging symbols (-g)
If people want to add --disable-debug, and document which is gcc and
non-gcc, that is fine with me.
Also, usually, you don't want to run the debugger on optimized code
unless you are debugging a compiler issue, so maybe we should call it
--debugging-symbols and --no-debugging-symbols to make it clear what the
option does.
Also, we should encourage packages to use --no-debugging-symbols rather
than 'strip'.
-- 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