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@dunslane.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-Xspecific, and non-standard, `optreset' global variable;      to reset the getopt() scanner, use `optind = 0;'
insteadof relying      on this non-standard, non-portable and now-unsupported feature.
 


cheers

andrew