Обсуждение: mingw configure failure workaround

The really horrid hack below fixes for me a MINGW/MSys problem that 
otherwise occurs inconsistently (fails on different links, and pretends 
to have succeeded), but reliably (every run at least one link will not 
actually have happened).

There are 2 parts - first we loop a few times until we succeed, and 
second after the loop we test that we have actually succeeded, and 
complain loudly otherwise.

The second part seems well worth doing. Nobody has yet come up with a 
reasonable alternative to the first part (other than making the user do 
it by hand, which defeats the whole purpose of configure).

So, the questions are: what parts of this should we do?
1) failure test only or
2) loop plus failure test or
3) nothing

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.

cheers

andrew


Index: configure
===================================================================
RCS file: /projects/cvsroot/pgsql-server/configure,v
retrieving revision 1.351
diff -c -w -r1.351 configure
*** configure   27 Apr 2004 20:09:27 -0000      1.351
--- configure   29 Apr 2004 20:17:06 -0000
***************
*** 19141,19151 ****
--- 19141,19160 ----  esac
  # Make a symlink if possible; otherwise try a hard link.
+ for linktry in 1 2 3 4 5; do  ln -s $ac_rel_source $ac_dest 2>/dev/null ||    ln $srcdir/$ac_source $ac_dest ||    {
{echo "$as_me:$LINENO: error: cannot link $ac_dest to 
 
$srcdir/$ac_source" >&5echo "$as_me: error: cannot link $ac_dest to $srcdir/$ac_source" >&2;}   { (exit 1); exit 1; };
}
+   test -e $ac_dest && break
+ done
+   test -e $ac_dest || + { { echo "$as_me:$LINENO: error: failed to 
link $ac_dest to $srcdir/$ac_source"
+  >&5
+ echo "$as_me: error: failed to link $ac_dest to $srcdir/$ac_source" >&2;}
+    { (exit 1); exit 1; }; }  done_ACEOF

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.

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.
        regards, tom lane

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

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> 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.

It's different because we know why we need that one: we understand the
cause of the behavior and we therefore can have some confidence that the
kluge will fix it (or not, as the case may be).  I have zero confidence
in looping five times around an "ln" call.
        regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>Tom Lane wrote:
>>    
>>
>>>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.
>>    
>>
>
>It's different because we know why we need that one: we understand the
>cause of the behavior and we therefore can have some confidence that the
>kluge will fix it (or not, as the case may be).  I have zero confidence
>in looping five times around an "ln" call.
>
>  
>

Even if we don't do that can we *please* put in something that detects 
the error, and tells the user what they will have to do to fix it? 
Failing in a situation which we know we can detect and not telling the 
user is intolerable, IMNSHO.

cheers

andrew

Andrew Dunstan wrote:
> >It's different because we know why we need that one: we understand the
> >cause of the behavior and we therefore can have some confidence that the
> >kluge will fix it (or not, as the case may be).  I have zero confidence
> >in looping five times around an "ln" call.
> >
> >  
> >
> 
> Even if we don't do that can we *please* put in something that detects 
> the error, and tells the user what they will have to do to fix it? 
> Failing in a situation which we know we can detect and not telling the 
> user is intolerable, IMNSHO.

Agreed.  At a minium we have to throw an error and tell them to run it
again.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Andrew Dunstan wrote:
> Even if we don't do that can we *please* put in something that
> detects the error, and tells the user what they will have to do to
> fix it? Failing in a situation which we know we can detect and not
> telling the user is intolerable, IMNSHO.

Can you try a more recent version of autoconf and see if that behaves 
more tolerably?

Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>  
>
>>Even if we don't do that can we *please* put in something that
>>detects the error, and tells the user what they will have to do to
>>fix it? Failing in a situation which we know we can detect and not
>>telling the user is intolerable, IMNSHO.
>>    
>>
>
>Can you try a more recent version of autoconf and see if that behaves 
>more tolerably?
>
>  
>

tested with autoconf 2.59.

Unfortunately, it does not. It does try to copy if a link fails, unlike 
what we have now:
 ln -s $ac_rel_source $ac_dest 2>/dev/null ||   ln $srcdir/$ac_source $ac_dest 2>/dev/null ||   cp -p
$srcdir/$ac_source$ac_dest ||
 

We don't have the last line, which must have been added since autoconf 2.53.

However, the problem is that the first line will actually appear to have 
succeeded, i.e. MSys's ln is lying to us ;-(

This comes from the autoconf macro _AC_OUTPUT_LINKS defined in its 
status.m4, which I guess is what we'd need to override (is that 
possible?) if we are going to detect the failure, or maybe there's some 
more magical way that in my unfamiliarity with autoconf I am unaware of.

cheers

andrew

Andrew Dunstan wrote:
> However, the problem is that the first line will actually appear to
> have succeeded, i.e. MSys's ln is lying to us ;-(

Then msys needs to be fixed.  There is certainly a bunch of 
autoconfiscated software that gets compiled on mingw/msys every day.  I 
would like to know why we are the only ones having this problem.  Has 
anyone contacted the msys authors about this?

> This comes from the autoconf macro _AC_OUTPUT_LINKS defined in its
> status.m4, which I guess is what we'd need to override (is that
> possible?)

No

> if we are going to detect the failure, or maybe there's
> some more magical way that in my unfamiliarity with autoconf I am
> unaware of.

No

Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>  
>
>>However, the problem is that the first line will actually appear to
>>have succeeded, i.e. MSys's ln is lying to us ;-(
>>    
>>
>
>Then msys needs to be fixed.  There is certainly a bunch of 
>autoconfiscated software that gets compiled on mingw/msys every day.  I 
>would like to know why we are the only ones having this problem.  Has 
>anyone contacted the msys authors about this?
>  
>

I don't know -  I recall hearing something, but I have found no trace. I 
will follow it up, but I do not think this absolves us of all 
responsibility. We work around all sorts of problems on all sorts of 
platforms.

>  
>
>>This comes from the autoconf macro _AC_OUTPUT_LINKS defined in its
>>status.m4, which I guess is what we'd need to override (is that
>>possible?)
>>    
>>
>
>No
>  
>

I will take your word for it, but see below.

>  
>
>>if we are going to detect the failure, or maybe there's
>>some more magical way that in my unfamiliarity with autoconf I am
>>unaware of.
>>    
>>
>
>No
>
>
>  
>
"No" is our answer too often.

A lot of reading and some experimentation showed that putting this in 
configure.in:

AC_OUTPUT_COMMANDS([ for linktarget in src/backend/port/dynloader.c 
src/backend/port/pg_sema.c src/backend/port/pg_shmem.c 
src/include/dynloader.h src/include/pg_config_os.h src/Makefile.port ; do   test -e $linktarget || echo " ***" link for
$linktargetfailed - 
 
please fix by hand done
])


yielded results looking like this:

config.status: executing default-1 commands*** link for src/backend/port/pg_shmem.c failed - please fix by hand*** link
forsrc/include/dynloader.h failed - please fix by hand
 

Which is more or less what I wanted as a minimum.


cheers

andrew

Andrew Dunstan wrote:

> Peter Eisentraut wrote:
>
>> Andrew Dunstan wrote:
>>  
>>
>>> Even if we don't do that can we *please* put in something that
>>> detects the error, and tells the user what they will have to do to
>>> fix it? Failing in a situation which we know we can detect and not
>>> telling the user is intolerable, IMNSHO.
>>>   
>>
>>
>> Can you try a more recent version of autoconf and see if that behaves 
>> more tolerably?
>>
>>  
>>
>
> tested with autoconf 2.59.
>
> Unfortunately, it does not. It does try to copy if a link fails, 
> unlike what we have now:
>
>  ln -s $ac_rel_source $ac_dest 2>/dev/null ||
>    ln $srcdir/$ac_source $ac_dest 2>/dev/null ||
>    cp -p $srcdir/$ac_source $ac_dest ||
>
> We don't have the last line, which must have been added since autoconf 
> 2.53.


I was ahead of myself. It does appear to work, (tested in the platform I 
was using to get reliable failure, with autoconf 2.56 from the MSysDTK).

I'm damned if I know why, though.

I still think we should cosider the little error detection macro I just 
posted.

cheers

andrew

> tested with autoconf 2.59.
>
> Unfortunately, it does not. It does try to copy if a link
> fails, unlike what we have now:
>
>   ln -s $ac_rel_source $ac_dest 2>/dev/null ||
>     ln $srcdir/$ac_source $ac_dest 2>/dev/null ||
>     cp -p $srcdir/$ac_source $ac_dest ||
>
> We don't have the last line, which must have been added since
> autoconf 2.53.
>
> However, the problem is that the first line will actually
> appear to have succeeded, i.e. MSys's ln is lying to us ;-(

Ok, how's this for a really ugly solution:

* Provide our own ln (in the form of a shellscript, even)
* Make sure this one gets in ahead of the system supplied one in the
path (from the code above it looks like it's not calling it with a
specific path, so just force-adding somethign to the path of configure
should work?)

This ln can then do a cp directly, and not even bother trying the mingw
ln function which we know will only do cp anyway if it succeeds.

If there is a less ugly solution to be had, by all means stay away from
thsi oen :-)

//Magnus