Re: mingw configure failure workaround - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: mingw configure failure workaround
Date
Msg-id 40940FF0.1020308@dunslane.net
Whole thread Raw
In response to Re: mingw configure failure workaround  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: mingw configure failure workaround  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>And if not 3), is there some autoconf wizard out there who can help do 
>>this properly? It would probably take me many hours to work out, as I 
>>have never touched the beast.
>>    
>>
>
>Obviously, or you would know that configure is a generated file that
>there is no point in editing by hand.
>

er ... that's why I asked how to do it properly. I simply included the 
diff to show what I had been able to make work, not because I wanted it 
applied.

>
>The real issue in my mind is why is "ln" unreliable in mingw?  I cannot
>see any point in a retry kluge when we do not know what's really going
>on.
>
>    
>

I'm still trying to find out. But I don't see why this is different from 
the kludge we already have for unlink, and that one is right inside 
postgresql. In fact. it's more or less the same solution.

At the very least, until we can find a better solution we should have 
something like the checking part of what I did. We've seen quite a 
number of obscure failure reports that have all been traced back to this 
failure, which is currently quite unreported by configure.

cheers

andrew



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: mingw configure failure workaround
Next
From: Tom Lane
Date:
Subject: Re: Weird prepared stmt behavior