Re: Complier warnings on mingw gcc 4.5.0

On 12/15/2010 02:22 PM, Andrew Dunstan wrote:
>
>
> 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.

And here is where it changed:
<http://sourceforge.net/project/shownotes.php?release_id=24832>

* A replacement implementation for the getopt() family of functions,
adding support for the GNU getopt_long_only() function. Users
should note that this intentionally *removes* support for the BSD
or Mac OS-X specific, and non-standard, `optreset' global variable;
to reset the getopt() scanner, use `optind = 0;' instead of relying
on this non-standard, non-portable and now-unsupported feature.

cheers

andrew