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

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?

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

--

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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:

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.

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

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

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