Bruce Momjian wrote:
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 arbitra
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
>
Bruce Momjian wrote:
pgman wrote:
Jan Wieck wrote:
> >> >> > 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,
> >> >> >
pgman wrote:
> Jan Wieck wrote:
> > >> >> > 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 p
Jan Wieck wrote:
> >> >> > 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
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> 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 pen
Bruce Momjian wrote:
> 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.
But doesn't --enable-debug turn off optimization?
It's really a question of what the default behavior s
Kevin Brown wrote:
> > > You do realize that as of now, -g is the default for gcc?
>
> It is?
>
> [EMAIL PROTECTED]:~/tmp$ gcc -c foo.c
> [EMAIL PROTECTED]:~/tmp$ ls -l foo.o
> -rw-r--r--1 kevinkevin 876 Oct 26 18:52 foo.o
> [EMAIL PROTECTED]:~/tmp$ gcc -g -c foo.c
> [EMAIL PROTEC
Jan Wieck wrote:
> Bruce Momjian wrote:
> > 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 fo
Bruce Momjian wrote:
> 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,
>
Bruce Momjian wrote:
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 be
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
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Also, I thought Peter advocated adding -g a few releases back.
>> I don't recall any such vote.
> The vote was whether -g should be used for a default compile.
> Here is the thread disc
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Also, I thought Peter advocated adding -g a few releases back. I didn't
> > > agree, but I lost the vote, so I thought it was done. Were we
> > > supresssing -g in older releases? Peter?
> >
> > I don't r
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The vote was whether -g should be used for a default compile. Of course
> > --enable-debug would continue using -g. Maybe we kept --enable-debug
> > for backward compatibility or to force -g if you modified CFLAGS?
>
> I can't see w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The vote was whether -g should be used for a default compile. Of course
> --enable-debug would continue using -g. Maybe we kept --enable-debug
> for backward compatibility or to force -g if you modified CFLAGS?
I can't see why we would have kept --enab
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Also, I thought Peter advocated adding -g a few releases back. I didn't
> > agree, but I lost the vote, so I thought it was done. Were we
> > supresssing -g in older releases? Peter?
>
> I don't recall any such vote. Had we done t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Also, I thought Peter advocated adding -g a few releases back. I didn't
> agree, but I lost the vote, so I thought it was done. Were we
> supresssing -g in older releases? Peter?
I don't recall any such vote. Had we done that, we'd have removed
--ena
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> 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 th
Greg Stark <[EMAIL PROTECTED]> 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 togethe
Tom Lane wrote:
> While fooling with adding -fno-strict-aliasing to configure, I realized
> that there are still some oddities about its selection of CFLAGS. The
> problems stem from the fact that autoconf will always select a default
> value of CFLAGS that includes "-g", if the compiler accepts "
While fooling with adding -fno-strict-aliasing to configure, I realized
that there are still some oddities about its selection of CFLAGS. The
problems stem from the fact that autoconf will always select a default
value of CFLAGS that includes "-g", if the compiler accepts "-g" at all.
This has a c
22 matches
Mail list logo
