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