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