Re: mingw check hung - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: mingw check hung
Date
Msg-id 49839494.50001@tpf.co.jp
Whole thread Raw
In response to Re: mingw check hung  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: mingw check hung  (Andrew Dunstan <andrew@dunslane.net>)
Re: mingw check hung  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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.

regards,
Hiroshi Inoue



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: How to get SE-PostgreSQL acceptable
Next
From: Andrew Dunstan
Date:
Subject: Re: mingw check hung