Hiroshi Inoue wrote:
> Andrew Dunstan wrote:
>>
>>
>> Andrew Dunstan wrote:
>>>
>>>
>>> Magnus Hagander wrote:
>>>> Andrew Dunstan wrote:
>>>>
>>>>> Magnus Hagander wrote:
>>>>>
>>>>>> Are we *sure*, btw, that this is actually a mingw issue, and not
>>>>>> something else in the environment? Could you try a MSVC compiled
>>>>>> binary
>>>>>> on the same machine?
>>>>>>
>>>>> My MSVC buildfarm animal runs on the same machine, and does not suffer
>>>>> the same problem.
>>>>>
>>>> Meh. Stupid mingw :-)
>>>>
>>>> So how about we #ifdef out that NULL setting based on
>>>> WIN32_ONLY_COMPILER, does that seem reasonable?
>>>>
>>> The odd thing is that it doesn't seem to affect Vista, only XP.
>>>
>>> Anyway, yes, I think that would be OK. How do we then test to see if
>>> the original problem is still fixed?
>>>
>> Further proof that this is a Windows version issue: I took the problem
>> build from my XP and put it on my Vista box: the same build that
>> causes a problem on XP runs perfectly on Vista. Go figure. Maybe we
>> need a version check at runtime? That would be icky.
>
> Eventually does the crash come from the call SetEnvironemntVariable
> (.., NULL) on mingw-XP(or older?)?
> I'm also interested in this issue and want to know the cause.
>
> However is it necessary to call SetEnvironmentVariable() in the first
> place? My original patch doesn't contain SetEnvironmentVariable call
> in pg_unsetenv() because _putenv() seems to call SetEnvironmentVariable
> internally.
It's because I factored in another place where we *did* call it explicitly.
Perhaps this code was put in for compatibility with some old version of
mingw or something? If everything works if we remove that call in both
msvc and mingw, we can just do that, yes. It still doesn't really
explain *why* it crashes though.
//Magnus
