
Below are a couple of diffs.

The first is the fix I made in configure - on my W2K machine with the 
current MinGW/MSys I was getting the previously reported symlink problem 
every time. With the looping patch (yes I *know* it's ugly, and we have 
to get to the root of the problem, but I wanted to get past it for now) 
it never happened, and builds worked. In any case we should use 
something like the last couple of lines at least, to *show* something 
went wrong. As we have it now we say we are doing something and not 
testing for failure.

The second allows "make check" to proceed to almost the end - you still 
need to use the task manager to shut things down.

The regression tests themselves seem to fail for the most part in every 
configuration I have tried. The problem seems to be mostly buffering 
issues - error messages appear out of order from what is expected. I 
have not made sure what passes if we ignore that issue.

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" >&5
  echo "$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
 
Index: src/test/regress/pg_regress.sh
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/test/regress/pg_regress.sh,v
retrieving revision 1.38
diff -c -w -r1.38 pg_regress.sh
*** src/test/regress/pg_regress.sh      8 Jan 2004 20:04:41 -0000       1.38
--- src/test/regress/pg_regress.sh      29 Apr 2004 20:17:07 -0000
***************
*** 294,305 ****
  if [ x"$temp_install" != x"" ]
  then
      if echo x"$temp_install" | grep -v '^x/' >/dev/null 2>&1; then
          temp_install="`pwd`/$temp_install"
      fi
 
      bindir=$temp_install/install/$bindir
      libdir=$temp_install/install/$libdir
-     pkglibdir=$temp_install/install/$pkglibdir
      datadir=$temp_install/install/$datadir
      PGDATA=$temp_install/data
 
--- 294,313 ----
  if [ x"$temp_install" != x"" ]
  then
      if echo x"$temp_install" | grep -v '^x/' >/dev/null 2>&1; then
+         case $host_platform in
+           *-*-mingw32*)
+                 pkglibdir="`pwd -W`/$temp_install/install/$pkglibdir"
+                 temp_install="`pwd`/$temp_install"
+                 ;;
+           *)
                  temp_install="`pwd`/$temp_install"
+                 pkglibdir=$temp_install/install/$pkglibdir
+                 ;;
+         esac
      fi
 
      bindir=$temp_install/install/$bindir
      libdir=$temp_install/install/$libdir
      datadir=$temp_install/install/$datadir
      PGDATA=$temp_install/data
 
***************
*** 336,342 ****
      # executables, not dlopen'ed ones)
      # ----------
      case $host_platform in
!         *-*-cygwin*)
              PATH=$libdir:$PATH
              export PATH
              ;;
--- 344,350 ----
      # executables, not dlopen'ed ones)
      # ----------
      case $host_platform in
!         *-*-cygwin* | *-*-mingw32*)
              PATH=$libdir:$PATH
              export PATH
              ;;



Thu, 29 Apr 2004 16:46:14 -0400
Andrew Dunstan <andrew@dunslane.net>
win32 build and test issues

I can apply the last part of this patch, but we can't patch configure,
only configure.in.   Can you think of a way to patch that instead?

---------------------------------------------------------------------------

Andrew Dunstan wrote:
> 
> Below are a couple of diffs.
> 
> The first is the fix I made in configure - on my W2K machine with the 
> current MinGW/MSys I was getting the previously reported symlink problem 
> every time. With the looping patch (yes I *know* it's ugly, and we have 
> to get to the root of the problem, but I wanted to get past it for now) 
> it never happened, and builds worked. In any case we should use 
> something like the last couple of lines at least, to *show* something 
> went wrong. As we have it now we say we are doing something and not 
> testing for failure.
> 
> The second allows "make check" to proceed to almost the end - you still 
> need to use the task manager to shut things down.
> 
> The regression tests themselves seem to fail for the most part in every 
> configuration I have tried. The problem seems to be mostly buffering 
> issues - error messages appear out of order from what is expected. I 
> have not made sure what passes if we ignore that issue.
> 
> 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" >&5
>   echo "$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
>  
> Index: src/test/regress/pg_regress.sh
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/test/regress/pg_regress.sh,v
> retrieving revision 1.38
> diff -c -w -r1.38 pg_regress.sh
> *** src/test/regress/pg_regress.sh      8 Jan 2004 20:04:41 -0000       1.38
> --- src/test/regress/pg_regress.sh      29 Apr 2004 20:17:07 -0000
> ***************
> *** 294,305 ****
>   if [ x"$temp_install" != x"" ]
>   then
>       if echo x"$temp_install" | grep -v '^x/' >/dev/null 2>&1; then
>           temp_install="`pwd`/$temp_install"
>       fi
>  
>       bindir=$temp_install/install/$bindir
>       libdir=$temp_install/install/$libdir
> -     pkglibdir=$temp_install/install/$pkglibdir
>       datadir=$temp_install/install/$datadir
>       PGDATA=$temp_install/data
>  
> --- 294,313 ----
>   if [ x"$temp_install" != x"" ]
>   then
>       if echo x"$temp_install" | grep -v '^x/' >/dev/null 2>&1; then
> +         case $host_platform in
> +           *-*-mingw32*)
> +                 pkglibdir="`pwd -W`/$temp_install/install/$pkglibdir"
> +                 temp_install="`pwd`/$temp_install"
> +                 ;;
> +           *)
>                   temp_install="`pwd`/$temp_install"
> +                 pkglibdir=$temp_install/install/$pkglibdir
> +                 ;;
> +         esac
>       fi
>  
>       bindir=$temp_install/install/$bindir
>       libdir=$temp_install/install/$libdir
>       datadir=$temp_install/install/$datadir
>       PGDATA=$temp_install/data
>  
> ***************
> *** 336,342 ****
>       # executables, not dlopen'ed ones)
>       # ----------
>       case $host_platform in
> !         *-*-cygwin*)
>               PATH=$libdir:$PATH
>               export PATH
>               ;;
> --- 344,350 ----
>       # executables, not dlopen'ed ones)
>       # ----------
>       case $host_platform in
> !         *-*-cygwin* | *-*-mingw32*)
>               PATH=$libdir:$PATH
>               export PATH
>               ;;
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
  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, Pennsylvania 19073

Fri, 30 Apr 2004 23:07:48 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: win32 build and test issues

This wasn't posted with a view to application. More a progress report.

Claudio has submitted a patch dealing with part of it.

I will look into the configure.in question in due course.

cheers

andrew

Bruce Momjian said:
>
> I can apply the last part of this patch, but we can't patch configure,
> only configure.in.   Can you think of a way to patch that instead?
>
> -------------------------------------------------------------------------
--
>
> Andrew Dunstan wrote:
>>
>> Below are a couple of diffs.
>>
>> The first is the fix I made in configure - on my W2K machine with the
>> current MinGW/MSys I was getting the previously reported symlink
>> problem  every time. With the looping patch (yes I *know* it's ugly,
>> and we have  to get to the root of the problem, but I wanted to get
>> past it for now)  it never happened, and builds worked. In any case we
>> should use  something like the last couple of lines at least, to
>> *show* something  went wrong. As we have it now we say we are doing
>> something and not  testing for failure.
>>
>> The second allows "make check" to proceed to almost the end - you
>> still  need to use the task manager to shut things down.
>>
>> The regression tests themselves seem to fail for the most part in
>> every  configuration I have tried. The problem seems to be mostly
>> buffering  issues - error messages appear out of order from what is
>> expected. I  have not made sure what passes if we ignore that issue.
>>
>> 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" >&5
>>   echo "$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
>>
>> Index: src/test/regress/pg_regress.sh
>> ===================================================================
>> RCS file:
>> /projects/cvsroot/pgsql-server/src/test/regress/pg_regress.sh,v
>> retrieving revision 1.38
>> diff -c -w -r1.38 pg_regress.sh
>> *** src/test/regress/pg_regress.sh      8 Jan 2004 20:04:41 -0000
>>  1.38 --- src/test/regress/pg_regress.sh      29 Apr 2004 20:17:07
>> -0000 ***************
>> *** 294,305 ****
>>   if [ x"$temp_install" != x"" ]
>>   then
>>       if echo x"$temp_install" | grep -v '^x/' >/dev/null 2>&1; then
>>           temp_install="`pwd`/$temp_install"
>>       fi
>>
>>       bindir=$temp_install/install/$bindir
>>       libdir=$temp_install/install/$libdir
>> -     pkglibdir=$temp_install/install/$pkglibdir
>>       datadir=$temp_install/install/$datadir
>>       PGDATA=$temp_install/data
>>
>> --- 294,313 ----
>>   if [ x"$temp_install" != x"" ]
>>   then
>>       if echo x"$temp_install" | grep -v '^x/' >/dev/null 2>&1; then
>> +         case $host_platform in
>> +           *-*-mingw32*)
>> +                 pkglibdir="`pwd
>> -W`/$temp_install/install/$pkglibdir" +
>> temp_install="`pwd`/$temp_install"
>> +                 ;;
>> +           *)
>>                   temp_install="`pwd`/$temp_install"
>> +                 pkglibdir=$temp_install/install/$pkglibdir
>> +                 ;;
>> +         esac
>>       fi
>>
>>       bindir=$temp_install/install/$bindir
>>       libdir=$temp_install/install/$libdir
>>       datadir=$temp_install/install/$datadir
>>       PGDATA=$temp_install/data
>>
>> ***************
>> *** 336,342 ****
>>       # executables, not dlopen'ed ones)
>>       # ----------
>>       case $host_platform in
>> !         *-*-cygwin*)
>>               PATH=$libdir:$PATH
>>               export PATH
>>               ;;
>> --- 344,350 ----
>>       # executables, not dlopen'ed ones)
>>       # ----------
>>       case $host_platform in
>> !         *-*-cygwin* | *-*-mingw32*)
>>               PATH=$libdir:$PATH
>>               export PATH
>>               ;;
>>
>>
>>
>> ---------------------------(end of
>> broadcast)--------------------------- TIP 1: subscribe and unsubscribe
>> commands go to majordomo@postgresql.org
>>
>
> --
>  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, Pennsylvania
>  19073




Fri, 30 Apr 2004 23:18:02 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: win32 build and test issues

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" >&5
 echo "$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



Sat, 01 May 2004 11:16:57 -0400
Andrew Dunstan <andrew@dunslane.net>
mingw configure failure workaround
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

Sat, 01 May 2004 16:42:20 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: mingw configure failure workaround 


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


Sat, 01 May 2004 17:00:32 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: mingw configure failure workaround
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

Sat, 01 May 2004 17:43:06 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: mingw configure failure workaround 


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


Sat, 01 May 2004 18:55:31 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: mingw configure failure workaround
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, Pennsylvania 19073

Sat, 1 May 2004 23:08:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mingw configure failure workaround
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?


Sun, 2 May 2004 09:44:25 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: mingw configure failure workaround
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



Mon, 03 May 2004 10:56:48 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: mingw configure failure workaround
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


Mon, 3 May 2004 20:02:47 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: mingw configure failure workaround
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 $linktarget failed - 
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 for src/include/dynloader.h failed - please fix by hand

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


cheers

andrew



Mon, 03 May 2004 16:11:44 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: mingw configure failure workaround
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




Mon, 03 May 2004 16:42:54 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: mingw configure failure workaround
Bruce Momjian wrote:

>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.
>  
>


This patch for configure.in detects the link failures in MINGW that I 
and others have seen and warns the user they have to fix it up.

cheers

andrew
Sat, 08 May 2004 15:02:48 -0400
Andrew Dunstan <andrew@dunslane.net>
mingw configure failure detection

I have added to the Win32 TODO to remove this when we find the real
cause for the link failures.

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Andrew Dunstan wrote:
> 
> 
> Bruce Momjian wrote:
> 
> >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.
> >  
> >
> 
> 
> This patch for configure.in detects the link failures in MINGW that I 
> and others have seen and warns the user they have to fix it up.
> 
> cheers
> 
> andrew

> Index: configure.in
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/configure.in,v
> retrieving revision 1.345
> diff -c -r1.345 configure.in
> *** configure.in	7 May 2004 00:24:57 -0000	1.345
> --- configure.in	8 May 2004 15:47:01 -0000
> ***************
> *** 1237,1242 ****
> --- 1237,1260 ----
>     src/Makefile.port:src/makefiles/Makefile.${template}
>   ])
>   
> + # Links sometimes fail undetected on Mingw - 
> + # so here we detect it and warn the user
> + case $host_os in mingw*)
> + AC_OUTPUT_COMMANDS([
> +  for linktarget in \
> + 	src/backend/port/tas.s \
> + 	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 $linktarget failed - please fix by hand
> +  done
> + ]) 
> + 	;;
> + esac
> + 
>   AC_CONFIG_HEADERS([src/include/pg_config.h],
>   [
>   # Update timestamp for pg_config.h (see Makefile.global)

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

-- 
  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, Pennsylvania 19073

Sat, 8 May 2004 15:14:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mingw configure failure detection
Andrew Dunstan wrote:
> This patch for configure.in detects the link failures in MINGW that I
> and others have seen and warns the user they have to fix it up.

I continue to object to these sort of patches if no one wants to bother 
to contact the mingw maintainers about this problem.  Maybe they have a 
better fix available?

Btw. test -e is not portable.  And please use AC_MSG_WARN instead of 
"echo".


Sun, 9 May 2004 13:41:38 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: mingw configure failure detection
Peter Eisentraut said:
> Andrew Dunstan wrote:
>> This patch for configure.in detects the link failures in MINGW that I
>> and others have seen and warns the user they have to fix it up.
>
> I continue to object to these sort of patches if no one wants to bother
>  to contact the mingw maintainers about this problem.  Maybe they have
> a  better fix available?
>

I have already said I would follow it up. But the problem exists today and
shouldn't be left until we get an answer. Maybe it will take a week or a
month, or there will be no good answer at all.

All this does is issue a warning.

This problem has happened to a number of users. So far the reponse has
largely been 'fix it by hand and move on'. I think our reputation is and
ought to be better than that.

> Btw. test -e is not portable.

Since this would only be run under Mingw, where it does work, why does
that matter?

> And please use AC_MSG_WARN instead of
> "echo".
>

I guess Bruce can make this change.

cheers

andrew



Sun, 9 May 2004 08:16:02 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: mingw configure failure detection
I said:
> Peter Eisentraut said:
>> Andrew Dunstan wrote:
>>> This patch for configure.in detects the link failures in MINGW that I
>>> and others have seen and warns the user they have to fix it up.
>>
>> I continue to object to these sort of patches if no one wants to
>> bother
>>  to contact the mingw maintainers about this problem.  Maybe they have
>> a  better fix available?
>>
>
> I have already said I would follow it up. But the problem exists today
> and shouldn't be left until we get an answer. Maybe it will take a week
> or a month, or there will be no good answer at all.
>

It appears that Dann Corbit has filed a MinGW bug on this, with accurate
problem description, but he received a less than stellar response. See

https://sourceforge.net/tracker/index.php?
func=detail&aid=931263&group_id=2435&atid=102435

(Despite previous speculation, he did indicate that the problem is
intermittent, not constant).

Cheers

andrew






Mon, 10 May 2004 03:17:46 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: mingw configure failure detection
Andrew Dunstan wrote:
> I said:
> > Peter Eisentraut said:
> >> Andrew Dunstan wrote:
> >>> This patch for configure.in detects the link failures in MINGW that I
> >>> and others have seen and warns the user they have to fix it up.
> >>
> >> I continue to object to these sort of patches if no one wants to
> >> bother
> >>  to contact the mingw maintainers about this problem.  Maybe they have
> >> a  better fix available?
> >>

Basically, we document the bug workaround on the Win32 TODO list, and
remove the item and the patch once we find a solution.

> > I have already said I would follow it up. But the problem exists today
> > and shouldn't be left until we get an answer. Maybe it will take a week
> > or a month, or there will be no good answer at all.
> >
> 
> It appears that Dann Corbit has filed a MinGW bug on this, with accurate
> problem description, but he received a less than stellar response. See
> 
> https://sourceforge.net/tracker/index.php?
> func=detail&aid=931263&group_id=2435&atid=102435
> 
> (Despite previous speculation, he did indicate that the problem is
> intermittent, not constant).

I think we satisfy the specifications mentioned by the person replying. 
Perhaps someone needs to follow up to state we are following the
specifications.

-- 
  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, Pennsylvania 19073

Mon, 10 May 2004 10:21:53 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mingw configure failure detection
Am Montag, 10. Mai 2004 09:17 schrieb Andrew Dunstan:
> It appears that Dann Corbit has filed a MinGW bug on this, with accurate
> problem description, but he received a less than stellar response. See
>
> https://sourceforge.net/tracker/index.php?
> func=detail&aid=931263&group_id=2435&atid=102435

I added a followup to this bug and he requests a minimal reproduceable 
example.  Can someone provide one?

Wed, 12 May 2004 17:01:33 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: mingw configure failure detection
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Montag, 10. Mai 2004 09:17 schrieb Andrew Dunstan:
>> It appears that Dann Corbit has filed a MinGW bug on this, with accurate
>> problem description, but he received a less than stellar response. See
>> 
>> https://sourceforge.net/tracker/index.php?
>> func=detail&aid=931263&group_id=2435&atid=102435

> I added a followup to this bug and he requests a minimal reproduceable 
> example.  Can someone provide one?

 From what we've been hearing, all you have to do is download current
Postgres (snapshot tarball or CVS pull) and try "configure" a few times
(with "make distclean" to clean up).  That's perhaps not minimal but it
should at least convince him the bug exists ...

			regards, tom lane

Wed, 12 May 2004 12:56:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: mingw configure failure detection 
Adjusted attached patch applied.  Thanks.

I didn't change 'test -e' because 'test -h' doesn't work (is symlink
test on my platform).  test -f actually works on symlinks too in MinGW,
strangely enough.  Anyway, the code is only run on MinGW so we don't
have to worry about other platforms.  I added a comment explaining it
works.

I got rid of the AC_CONFIG_COMMANDS and just do the for/test loop in the
shell code directly.  AC_CONFIG_COMMANDS wouldn't allow me to call
AC_MSG_WARN.

---------------------------------------------------------------------------


Peter Eisentraut wrote:
> Andrew Dunstan wrote:
> > This patch for configure.in detects the link failures in MINGW that I
> > and others have seen and warns the user they have to fix it up.
> 
> I continue to object to these sort of patches if no one wants to bother 
> to contact the mingw maintainers about this problem.  Maybe they have a 
> better fix available?
> 
> Btw. test -e is not portable.  And please use AC_MSG_WARN instead of 
> "echo".
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
  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, Pennsylvania 19073

Index: configure
===================================================================
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.358
diff -c -c -r1.358 configure
*** configure	11 May 2004 21:57:13 -0000	1.358
--- configure	13 May 2004 01:26:20 -0000
***************
*** 17974,17979 ****
--- 17974,17998 ----
  ac_config_links="$ac_config_links src/backend/port/dynloader.c:src/backend/port/dynloader/${template}.c src/backend/port/pg_sema.c:${SEMA_IMPLEMENTATION} src/backend/port/pg_shmem.c:${SHMEM_IMPLEMENTATION} src/include/dynloader.h:src/backend/port/dynloader/${template}.h src/include/pg_config_os.h:src/include/port/${template}.h src/Makefile.port:src/makefiles/Makefile.${template}"
  
  
+ # Links sometimes fail undetected on Mingw -
+ # so here we detect it and warn the user
+ case $host_os in mingw*)
+  for linktarget in \
+ 	src/backend/port/tas.s \
+ 	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 works for symlinks in the MinGW console
+ 	test -e $linktarget || { echo "$as_me:$LINENO: WARNING: *** link for $linktarget failed - please fix by hand" >&5
+ echo "$as_me: WARNING: *** link for $linktarget failed - please fix by hand" >&2;}
+  done
+ 	;;
+ esac
+ 
  ac_config_headers="$ac_config_headers src/include/pg_config.h"
  
  
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.346
diff -c -c -r1.346 configure.in
*** configure.in	11 May 2004 21:57:13 -0000	1.346
--- configure.in	13 May 2004 01:26:22 -0000
***************
*** 1236,1241 ****
--- 1236,1259 ----
    src/Makefile.port:src/makefiles/Makefile.${template}
  ])
  
+ # Links sometimes fail undetected on Mingw - 
+ # so here we detect it and warn the user
+ case $host_os in mingw*)
+  for linktarget in \
+ 	src/backend/port/tas.s \
+ 	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 works for symlinks in the MinGW console
+ 	test -e $linktarget || AC_MSG_WARN([*** link for $linktarget failed - please fix by hand])
+  done
+ 	;;
+ esac
+ 
  AC_CONFIG_HEADERS([src/include/pg_config.h],
  [
  # Update timestamp for pg_config.h (see Makefile.global)
Wed, 12 May 2004 21:29:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mingw configure failure detection
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Am Montag, 10. Mai 2004 09:17 schrieb Andrew Dunstan:
> >> It appears that Dann Corbit has filed a MinGW bug on this, with accurate
> >> problem description, but he received a less than stellar response. See
> >> 
> >> https://sourceforge.net/tracker/index.php?
> >> func=detail&aid=931263&group_id=2435&atid=102435
> 
> > I added a followup to this bug and he requests a minimal reproduceable 
> > example.  Can someone provide one?
> 
> >From what we've been hearing, all you have to do is download current
> Postgres (snapshot tarball or CVS pull) and try "configure" a few times
> (with "make distclean" to clean up).  That's perhaps not minimal but it
> should at least convince him the bug exists ...

I just installed the configure symlink test code that throws a warning
if the symlinks don't work, so it is even easier to test now.  Just run
configure until it fails --- nothing to compile.

-- 
  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, Pennsylvania 19073

Wed, 12 May 2004 21:31:03 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mingw configure failure detection

The patch as applied is totally broken - the tests have to be run by 
config.status after it has actually tried to make the links, which is 
why I used AC_CONFIG_COMMANDS.

cheers

andrew


Bruce Momjian wrote:

>Adjusted attached patch applied.  Thanks.
>
>I didn't change 'test -e' because 'test -h' doesn't work (is symlink
>test on my platform).  test -f actually works on symlinks too in MinGW,
>strangely enough.  Anyway, the code is only run on MinGW so we don't
>have to worry about other platforms.  I added a comment explaining it
>works.
>
>I got rid of the AC_CONFIG_COMMANDS and just do the for/test loop in the
>shell code directly.  AC_CONFIG_COMMANDS wouldn't allow me to call
>AC_MSG_WARN.
>
>---------------------------------------------------------------------------
>
>
>Peter Eisentraut wrote:
>  
>
>>Andrew Dunstan wrote:
>>    
>>
>>>This patch for configure.in detects the link failures in MINGW that I
>>>and others have seen and warns the user they have to fix it up.
>>>      
>>>
>>I continue to object to these sort of patches if no one wants to bother 
>>to contact the mingw maintainers about this problem.  Maybe they have a 
>>better fix available?
>>
>>Btw. test -e is not portable.  And please use AC_MSG_WARN instead of 
>>"echo".
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>>
>>    
>>
>
>  
>
>------------------------------------------------------------------------
>
>Index: configure
>===================================================================
>RCS file: /cvsroot/pgsql-server/configure,v
>retrieving revision 1.358
>diff -c -c -r1.358 configure
>*** configure	11 May 2004 21:57:13 -0000	1.358
>--- configure	13 May 2004 01:26:20 -0000
>***************
>*** 17974,17979 ****
>--- 17974,17998 ----
>  ac_config_links="$ac_config_links src/backend/port/dynloader.c:src/backend/port/dynloader/${template}.c src/backend/port/pg_sema.c:${SEMA_IMPLEMENTATION} src/backend/port/pg_shmem.c:${SHMEM_IMPLEMENTATION} src/include/dynloader.h:src/backend/port/dynloader/${template}.h src/include/pg_config_os.h:src/include/port/${template}.h src/Makefile.port:src/makefiles/Makefile.${template}"
>  
>  
>+ # Links sometimes fail undetected on Mingw -
>+ # so here we detect it and warn the user
>+ case $host_os in mingw*)
>+  for linktarget in \
>+ 	src/backend/port/tas.s \
>+ 	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 works for symlinks in the MinGW console
>+ 	test -e $linktarget || { echo "$as_me:$LINENO: WARNING: *** link for $linktarget failed - please fix by hand" >&5
>+ echo "$as_me: WARNING: *** link for $linktarget failed - please fix by hand" >&2;}
>+  done
>+ 	;;
>+ esac
>+ 
>  ac_config_headers="$ac_config_headers src/include/pg_config.h"
>  
>  
>Index: configure.in
>===================================================================
>RCS file: /cvsroot/pgsql-server/configure.in,v
>retrieving revision 1.346
>diff -c -c -r1.346 configure.in
>*** configure.in	11 May 2004 21:57:13 -0000	1.346
>--- configure.in	13 May 2004 01:26:22 -0000
>***************
>*** 1236,1241 ****
>--- 1236,1259 ----
>    src/Makefile.port:src/makefiles/Makefile.${template}
>  ])
>  
>+ # Links sometimes fail undetected on Mingw - 
>+ # so here we detect it and warn the user
>+ case $host_os in mingw*)
>+  for linktarget in \
>+ 	src/backend/port/tas.s \
>+ 	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 works for symlinks in the MinGW console
>+ 	test -e $linktarget || AC_MSG_WARN([*** link for $linktarget failed - please fix by hand])
>+  done
>+ 	;;
>+ esac
>+ 
>  AC_CONFIG_HEADERS([src/include/pg_config.h],
>  [
>  # Update timestamp for pg_config.h (see Makefile.global)
>  
>
>------------------------------------------------------------------------
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>               http://archives.postgresql.org
>  
>


Thu, 13 May 2004 12:19:12 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: mingw configure failure detection
Andrew Dunstan wrote:
> The patch as applied is totally broken - the tests have to be run by
> config.status after it has actually tried to make the links, which is
> why I used AC_CONFIG_COMMANDS.

Additional note: Instead of listing the files explicitly, just use 
$CONFIG_LINKS, which contains the list of files.


Thu, 13 May 2004 20:35:04 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: mingw configure failure detection
Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>  
>
>>The patch as applied is totally broken - the tests have to be run by
>>config.status after it has actually tried to make the links, which is
>>why I used AC_CONFIG_COMMANDS.
>>    
>>
>
>Additional note: Instead of listing the files explicitly, just use 
>$CONFIG_LINKS, which contains the list of files.
>
>
>  
>

Well, yes, except that each entry there is in the form 
linkname:targetname - we'd have to have extra code to split them up. 
Something like:

for ac_file in : $CONFIG_LINKS; do test "x$ac_file" = x: && continue
  linktry=`echo "$ac_file" | sed 's,:.*,,'`
  test ......
done


cheers

andrew


Thu, 13 May 2004 16:35:08 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: mingw configure failure detection
Andrew Dunstan wrote:
> Peter Eisentraut wrote:
> 
> >Andrew Dunstan wrote:
> >  
> >
> >>The patch as applied is totally broken - the tests have to be run by
> >>config.status after it has actually tried to make the links, which is
> >>why I used AC_CONFIG_COMMANDS.
> >>    
> >>
> >
> >Additional note: Instead of listing the files explicitly, just use 
> >$CONFIG_LINKS, which contains the list of files.
> >
> >
> >  
> >
> 
> Well, yes, except that each entry there is in the form 
> linkname:targetname - we'd have to have extra code to split them up. 
> Something like:
> 
> for ac_file in : $CONFIG_LINKS; do test "x$ac_file" = x: && continue
>   linktry=`echo "$ac_file" | sed 's,:.*,,'`
>   test ......
> done

OK, attached patch applied.

-- 
  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, Pennsylvania 19073

Index: configure
===================================================================
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.359
diff -c -c -r1.359 configure
*** configure	13 May 2004 01:44:59 -0000	1.359
--- configure	13 May 2004 22:56:38 -0000
***************
*** 17974,17998 ****
  ac_config_links="$ac_config_links src/backend/port/dynloader.c:src/backend/port/dynloader/${template}.c src/backend/port/pg_sema.c:${SEMA_IMPLEMENTATION} src/backend/port/pg_shmem.c:${SHMEM_IMPLEMENTATION} src/include/dynloader.h:src/backend/port/dynloader/${template}.h src/include/pg_config_os.h:src/include/port/${template}.h src/Makefile.port:src/makefiles/Makefile.${template}"
  
  
- # Links sometimes fail undetected on Mingw -
- # so here we detect it and warn the user
- case $host_os in mingw*)
-  for linktarget in \
- 	src/backend/port/tas.s \
- 	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 works for symlinks in the MinGW console
- 	test -e $linktarget || { echo "$as_me:$LINENO: WARNING: *** link for $linktarget failed - please fix by hand" >&5
- echo "$as_me: WARNING: *** link for $linktarget failed - please fix by hand" >&2;}
-  done
- 	;;
- esac
- 
  ac_config_headers="$ac_config_headers src/include/pg_config.h"
  
  
--- 17974,17979 ----
***************
*** 19200,19203 ****
--- 19181,19197 ----
    # would make configure fail if this is the last instruction.
    $ac_cs_success || { (exit 1); exit 1; }
  fi
+ 
+ 
+ # Links sometimes fail undetected on Mingw -
+ # so here we detect it and warn the user
+ case $host_os in mingw*)
+ for FILE in "$CONFIG_LINKS"
+  do
+ 	# test -e works for symlinks in the MinGW console
+ 	test -e `expr "$FILE" : '\(^:*\)'` || { echo "$as_me:$LINENO: WARNING: *** link for $FILE - please fix by hand" >&5
+ echo "$as_me: WARNING: *** link for $FILE - please fix by hand" >&2;}
+  done
+ 	;;
+ esac
  
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.347
diff -c -c -r1.347 configure.in
*** configure.in	13 May 2004 01:45:02 -0000	1.347
--- configure.in	13 May 2004 22:56:39 -0000
***************
*** 1236,1263 ****
    src/Makefile.port:src/makefiles/Makefile.${template}
  ])
  
  # Links sometimes fail undetected on Mingw - 
  # so here we detect it and warn the user
  case $host_os in mingw*)
!  for linktarget in \
! 	src/backend/port/tas.s \
! 	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 works for symlinks in the MinGW console
! 	test -e $linktarget || AC_MSG_WARN([*** link for $linktarget failed - please fix by hand])
   done
  	;;
  esac
  
- AC_CONFIG_HEADERS([src/include/pg_config.h],
- [
- # Update timestamp for pg_config.h (see Makefile.global)
- echo >src/include/stamp-h
- ])
- 
- AC_OUTPUT
--- 1236,1257 ----
    src/Makefile.port:src/makefiles/Makefile.${template}
  ])
  
+ AC_CONFIG_HEADERS([src/include/pg_config.h],
+ [
+ # Update timestamp for pg_config.h (see Makefile.global)
+ echo >src/include/stamp-h
+ ])
+ 
+ AC_OUTPUT
+ 
  # Links sometimes fail undetected on Mingw - 
  # so here we detect it and warn the user
  case $host_os in mingw*)
! for FILE in "$CONFIG_LINKS"
   do
  	# test -e works for symlinks in the MinGW console
! 	test -e `expr "$FILE" : '\([^:]*\)'` || AC_MSG_WARN([*** link for $FILE - please fix by hand])
   done
  	;;
  esac
Thu, 13 May 2004 18:59:31 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: mingw configure failure detection
Andrew Dunstan wrote:
> 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 $linktarget failed - 
> 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 for src/include/dynloader.h failed - please fix by hand

Change made and applied:
	
	case $host_os in mingw*)
	AC_OUTPUT_COMMANDS([
	# Links sometimes fail undetected on Mingw -
	# so here we detect it and warn the user
	for FILE in "$CONFIG_LINKS"
	 do
	        # test -e works for symlinks in the MinGW console
	        # We can't call AC_MSG_WARN from here, so we expand it
	        test -e `expr "$FILE" : '\(^:*\)'` || { echo "$as_me:$LINENO:
	WARNING: *** link for $FILE - please fix by hand" >&5
	echo "$as_me: WARNING: *** link for $FILE - please fix by hand" >&2;}
	 done
	])
	        ;;
	esac

The macro only runs on MinGW, of course.

-- 
  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, Pennsylvania 19073

Mon, 17 May 2004 15:13:15 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] mingw configure failure workaround