Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>> Specifically, it's the SetEnvironmentVariable() call from
>>> pgwin32_putenv() called from pgwin32_unsetenv(). When this is disabled
>>> things work just fine.
>>>
>>
>> That's strange :( What arguments are it sent to the function? Since this
>> is an API function, it really shouldn't behave differently between mingw
>> and msvc, so it must be something that goes wrong with the arguments.
>>
>> Also, Tom mentioned earlier that we may be including *two* replacements
>> for unsetenv(), which could be what's causing the problem. Can you check
>> if that is happening and try to disable the one in port/unsetenv.c and
>> see if that changes things?
>>
>>
>>
>
> I've already ruled out that hypothesis by forcing the call direct to
> pgwin32_unsetenv() instead of relying on the macro, in initdb.c.
>
> There are only two such calls in initdb.c: the arguments are "LC_ALL"
> and "PGCLIENTENCODING".
>
> I wonder if this version of SetEnvironmentVariable is sufficiently dumb
> that it fails badly if given a NULL second argument for a value that is
> not in fact in the environment (as I would normally expect of these on
> Windows)?
But that should be a win32 API call. It's not a runtime call. So it
should be identical between mingw and msvc!
Try removing the code that sets it to NULL if it's empty string. Having
it as empty string made it fail on MSVC, and the API documentation says
it should be NULL, but maybe mingw is somehow intercepting the call and
breaking it...
//Magnus
