From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:22:51 |
Message-ID: | 4D09158B.2050102@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/15/2010 02:06 PM, Tom Lane wrote:
> 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.
>
>
Sure we are closer to understanding it. It seems quite clear to me that
Mingw's getopt, which we have been using, has changed between versions,
as indicated by the fact that on my mingw optreset is not found, but on
narwhal it is found.
I haven't looked into our getopt.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitriy Igrishin | 2010-12-15 19:35:21 | Re: hstores in pl/python |
Previous Message | Dmitriy Igrishin | 2010-12-15 19:21:35 | Re: hstores in pl/python |