| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Complier warnings on mingw gcc 4.5.0 |
| Date: | 2010-12-15 19:06:57 |
| Message-ID: | 9654.1292440017@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> And the attached hack allowed "make check" to succeed.
> I think the logic in tcop/postgres.c and postmaster/postmaster.c is
> probably wrong. If we are using our getopt/getopt_long, we want to be
> setting optreset, whether or not configure found one in the system
> libraries.
Yeah, that's what I suggested earlier; but if your build *wasn't* using
our versions before, we're still no closer to understanding why it was
failing then. Another small problem is that a close inspection of our
getopt.c says that it does reset "place" to point at a constant before
returning -1, in every path except the "--" case which I doubt is being
invoked. So my idea that we were clobbering argv underneath it doesn't
seem to hold up. I'm still feeling that we don't understand what's
happening.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-12-15 19:12:45 | Re: [PATCH] V3: Idle in transaction cancellation |
| Previous Message | Andrew Dunstan | 2010-12-15 18:59:41 | Re: Complier warnings on mingw gcc 4.5.0 |