Обсуждение: win32 build and test issues
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
;;
> 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. FWIW, I agree. I'd rather have a few unfortunate lines in the configure code, than a few hundred (or more) questions from Win32 users asking why they can't build. > 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. It is a MingW problem. Appears like there is not much we can do about it. Refer to http://momjian.postgresql.org/main/writings/pgsql/win32.html for details on how to test outside of Ming. Also shows that HEAD passes all but 8 tests. Of those, 7 are due to pre-1970 date issues, and 1 appears to be an unimportant reordering of results. When the new time code is dropped in, I'm guessing we'll only have that single join test "failing" (FWIW, with the time code wedged in and a couple of ORDER BYs on the join test, my source base passes all tests). Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
> Also shows that HEAD passes all but 8 tests. Of those, 7 are > due to pre-1970 date issues, and 1 appears to be an > unimportant reordering of results. When the new time code is > dropped in, I'm guessing we'll only have that single join > test "failing" (FWIW, with the time code wedged in and a > couple of ORDER BYs on the join test, my source base passes > all tests). There are still locale issues if your main locale *in windows* is not english (independent of locale settings in pgsql). For those of us in that situation, there will be at least one possiblyi two more failures. //Magnus
Claudio Natoli said: > > >> 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. > > FWIW, I agree. I'd rather have a few unfortunate lines in the configure > code, than a few hundred (or more) questions from Win32 users asking > why they can't build. > Yeah. I think we need either to do something like what I did or find a better solution. > >> 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. > > It is a MingW problem. Appears like there is not much we can do about > it. Refer to > http://momjian.postgresql.org/main/writings/pgsql/win32.html for > details on how to test outside of Ming. > I am not giving up on it yet. I have a couple of ideas I'm going to try. Telling people they have to run the tests under cygwin is just horrible. cheers andrew
Andrew Dunstan wrote: >>>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. >>> >>> >>It is a MingW problem. Appears like there is not much we can do about >>it. Refer to >>http://momjian.postgresql.org/main/writings/pgsql/win32.html for >>details on how to test outside of Ming. >> >> >> > > >I am not giving up on it yet. I have a couple of ideas I'm going to try. >Telling people they have to run the tests under cygwin is just horrible. > > > The following near the start of psql gets rid of the "errors out of order" problem: #ifdef WIN32 setvbuf(stderr,NULL,_IONBF,0); #endif Of course, this is the Unix default, and should be for Windows, too, but it's small compared with the other things that have been overcome. I'm chasing down the other stuff - I suspect the extra lines might have some relation to binary/text mode for files. I'm also thinking of creating a simple commandline interface for pqkill that can be used to make a clean shutdown. cheers andrew
>I'm also thinking of creating a simple commandline interface >for pqkill >that can be used to make a clean shutdown. See the win32 status page, there is a link to one already. //Magnus
Magnus Hagander wrote:
>>I'm also thinking of creating a simple commandline interface
>>for pqkill
>>that can be used to make a clean shutdown.
>>
>>
>
>See the win32 status page, there is a link to one already.
>
>//Magnus
>
>
>
I will check it out. Meanwhile, there's promising news. With the patch
below applied to psql, I can run "make check" under MinGW and get all
but 12 tests passing. The remainder appear to be all related to the
timestamp issue, the floating point scientific format issue, and the
join sort order issue, which have been previously noted.
I'm not suggesting applying the patch yet - I'd like to know why the
line end thing cares what platform it is using - presumably regardless
of where it runs it is still using MSVCRT.
cheers
andrew
Index: startup.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
retrieving revision 1.91
diff -c -w -r1.91 startup.c
*** startup.c 22 Apr 2004 14:34:38 -0000 1.91
--- startup.c 30 Apr 2004 16:44:45 -0000
***************
*** 124,129 ****
--- 124,132 ----
}
}
+ #ifdef WIN32
+ setvbuf(stderr,NULL,_IONBF,0);
+ #endif
pset.cur_cmd_source = stdin;
pset.cur_cmd_interactive = false;
pset.encoding = PQenv2encoding();
Index: print.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/print.c,v
retrieving revision 1.46
diff -c -w -r1.46 print.c
*** print.c 24 Jan 2004 20:43:26 -0000 1.46
--- print.c 30 Apr 2004 16:44:46 -0000
***************
*** 388,394 ****
--- 388,396 ----
for (ptr = footers; *ptr; ptr++)
fprintf(fout, "%s\n", *ptr);
+ #ifndef WIN32
fputc('\n', fout);
+ #endif
/* clean up */
free(cell_w);
> > I will check it out. Meanwhile, there's promising news. With > the patch below applied to psql, I can run "make check" under MinGW Nice catch Andrew! Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
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:
> Magnus Hagander wrote:
>
> >>I'm also thinking of creating a simple commandline interface
> >>for pqkill
> >>that can be used to make a clean shutdown.
> >>
> >>
> >
> >See the win32 status page, there is a link to one already.
> >
> >//Magnus
> >
> >
> >
>
> I will check it out. Meanwhile, there's promising news. With the patch
> below applied to psql, I can run "make check" under MinGW and get all
> but 12 tests passing. The remainder appear to be all related to the
> timestamp issue, the floating point scientific format issue, and the
> join sort order issue, which have been previously noted.
>
> I'm not suggesting applying the patch yet - I'd like to know why the
> line end thing cares what platform it is using - presumably regardless
> of where it runs it is still using MSVCRT.
>
> cheers
>
> andrew
>
>
>
> Index: startup.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
> retrieving revision 1.91
> diff -c -w -r1.91 startup.c
> *** startup.c 22 Apr 2004 14:34:38 -0000 1.91
> --- startup.c 30 Apr 2004 16:44:45 -0000
> ***************
> *** 124,129 ****
> --- 124,132 ----
> }
> }
>
> + #ifdef WIN32
> + setvbuf(stderr,NULL,_IONBF,0);
> + #endif
> pset.cur_cmd_source = stdin;
> pset.cur_cmd_interactive = false;
> pset.encoding = PQenv2encoding();
> Index: print.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/print.c,v
> retrieving revision 1.46
> diff -c -w -r1.46 print.c
> *** print.c 24 Jan 2004 20:43:26 -0000 1.46
> --- print.c 30 Apr 2004 16:44:46 -0000
> ***************
> *** 388,394 ****
> --- 388,396 ----
> for (ptr = footers; *ptr; ptr++)
> fprintf(fout, "%s\n", *ptr);
>
> + #ifndef WIN32
> fputc('\n', fout);
> + #endif
>
> /* clean up */
> free(cell_w);
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" 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
Bruce, the setvbuf patch for startup.c should be applied, as all it does is ensure well understood and expected (i.e. = Unix) behaviour for stderr on Win32. I am not happy about the patch for print.c unless I can work out *why* it works, or someone can explain it to me. (That's why i made the comment below about not applying it, and didn't send it to -patches.) cheers andrew Bruce Momjian said: > > 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: >> Magnus Hagander wrote: >> >> >>I'm also thinking of creating a simple commandline interface >> >>for pqkill >> >>that can be used to make a clean shutdown. >> >> >> >> >> > >> >See the win32 status page, there is a link to one already. >> > >> >//Magnus >> > >> > >> > >> >> I will check it out. Meanwhile, there's promising news. With the patch >> below applied to psql, I can run "make check" under MinGW and get all >> but 12 tests passing. The remainder appear to be all related to the >> timestamp issue, the floating point scientific format issue, and the >> join sort order issue, which have been previously noted. >> >> I'm not suggesting applying the patch yet - I'd like to know why the >> line end thing cares what platform it is using - presumably regardless >> of where it runs it is still using MSVCRT. >> >> cheers >> >> andrew >> >> >> >> Index: startup.c >> =================================================================== >> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v >> retrieving revision 1.91 >> diff -c -w -r1.91 startup.c >> *** startup.c 22 Apr 2004 14:34:38 -0000 1.91 >> --- startup.c 30 Apr 2004 16:44:45 -0000 >> *************** >> *** 124,129 **** >> --- 124,132 ---- >> } >> } >> >> + #ifdef WIN32 >> + setvbuf(stderr,NULL,_IONBF,0); >> + #endif >> pset.cur_cmd_source = stdin; >> pset.cur_cmd_interactive = false; >> pset.encoding = PQenv2encoding(); >> Index: print.c >> =================================================================== >> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/print.c,v >> retrieving revision 1.46 >> diff -c -w -r1.46 print.c >> *** print.c 24 Jan 2004 20:43:26 -0000 1.46 >> --- print.c 30 Apr 2004 16:44:46 -0000 >> *************** >> *** 388,394 **** >> --- 388,396 ---- >> for (ptr = footers; *ptr; ptr++) >> fprintf(fout, "%s\n", *ptr); >> >> + #ifndef WIN32 >> fputc('\n', fout); >> + #endif >> >> /* clean up */ >> free(cell_w); >>
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
OK will apply only the first part. --------------------------------------------------------------------------- Andrew Dunstan wrote: > > > Bruce, > > the setvbuf patch for startup.c should be applied, as all it does is > ensure well understood and expected (i.e. = Unix) behaviour for stderr on > Win32. > > I am not happy about the patch for print.c unless I can work out *why* it > works, or someone can explain it to me. (That's why i made the comment > below about not applying it, and didn't send it to -patches.) > > cheers > > andrew > > > > Bruce Momjian said: > > > > 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: > >> Magnus Hagander wrote: > >> > >> >>I'm also thinking of creating a simple commandline interface > >> >>for pqkill > >> >>that can be used to make a clean shutdown. > >> >> > >> >> > >> > > >> >See the win32 status page, there is a link to one already. > >> > > >> >//Magnus > >> > > >> > > >> > > >> > >> I will check it out. Meanwhile, there's promising news. With the patch > >> below applied to psql, I can run "make check" under MinGW and get all > >> but 12 tests passing. The remainder appear to be all related to the > >> timestamp issue, the floating point scientific format issue, and the > >> join sort order issue, which have been previously noted. > >> > >> I'm not suggesting applying the patch yet - I'd like to know why the > >> line end thing cares what platform it is using - presumably regardless > >> of where it runs it is still using MSVCRT. > >> > >> cheers > >> > >> andrew > >> > >> > >> > >> Index: startup.c > >> =================================================================== > >> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v > >> retrieving revision 1.91 > >> diff -c -w -r1.91 startup.c > >> *** startup.c 22 Apr 2004 14:34:38 -0000 1.91 > >> --- startup.c 30 Apr 2004 16:44:45 -0000 > >> *************** > >> *** 124,129 **** > >> --- 124,132 ---- > >> } > >> } > >> > >> + #ifdef WIN32 > >> + setvbuf(stderr,NULL,_IONBF,0); > >> + #endif > >> pset.cur_cmd_source = stdin; > >> pset.cur_cmd_interactive = false; > >> pset.encoding = PQenv2encoding(); > >> Index: print.c > >> =================================================================== > >> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/print.c,v > >> retrieving revision 1.46 > >> diff -c -w -r1.46 print.c > >> *** print.c 24 Jan 2004 20:43:26 -0000 1.46 > >> --- print.c 30 Apr 2004 16:44:46 -0000 > >> *************** > >> *** 388,394 **** > >> --- 388,396 ---- > >> for (ptr = footers; *ptr; ptr++) > >> fprintf(fout, "%s\n", *ptr); > >> > >> + #ifndef WIN32 > >> fputc('\n', fout); > >> + #endif > >> > >> /* clean up */ > >> free(cell_w); > >> > > > > > ---------------------------(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?
>
> -------------------------------------------------------------------------
--
>
> 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
I have tried very hard to work out why this patch works for the
regression tests in MINGW/MSys, but it doesn't make any sense why this
one call should add an extra blank line. Does anyone have any bright
ideas? I'm reluctant to say I think we should apply it until the problem
is understood and the behaviour explained. But it does appear to work.
cheers
andrew
>>>>Index: print.c
>>>>===================================================================
>>>>RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/print.c,v
>>>>retrieving revision 1.46
>>>>diff -c -w -r1.46 print.c
>>>>*** print.c 24 Jan 2004 20:43:26 -0000 1.46
>>>>--- print.c 30 Apr 2004 16:44:46 -0000
>>>>***************
>>>>*** 388,394 ****
>>>>--- 388,396 ----
>>>> for (ptr = footers; *ptr; ptr++)
>>>> fprintf(fout, "%s\n", *ptr);
>>>>
>>>>+ #ifndef WIN32
>>>> fputc('\n', fout);
>>>>+ #endif
>>>>
>>>> /* clean up */
>>>> free(cell_w);
>>>>
>>>>
>>>>
Andrew, can you illustrate to the group the exact difference in output?
---------------------------------------------------------------------------
Andrew Dunstan wrote:
>
> I have tried very hard to work out why this patch works for the
> regression tests in MINGW/MSys, but it doesn't make any sense why this
> one call should add an extra blank line. Does anyone have any bright
> ideas? I'm reluctant to say I think we should apply it until the problem
> is understood and the behaviour explained. But it does appear to work.
>
> cheers
>
> andrew
>
>
>
> >>>>Index: print.c
> >>>>===================================================================
> >>>>RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/print.c,v
> >>>>retrieving revision 1.46
> >>>>diff -c -w -r1.46 print.c
> >>>>*** print.c 24 Jan 2004 20:43:26 -0000 1.46
> >>>>--- print.c 30 Apr 2004 16:44:46 -0000
> >>>>***************
> >>>>*** 388,394 ****
> >>>>--- 388,396 ----
> >>>> for (ptr = footers; *ptr; ptr++)
> >>>> fprintf(fout, "%s\n", *ptr);
> >>>>
> >>>>+ #ifndef WIN32
> >>>> fputc('\n', fout);
> >>>>+ #endif
> >>>>
> >>>> /* clean up */
> >>>> free(cell_w);
> >>>>
> >>>>
> >>>>
>
>
>
>
> ---------------------------(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
I will post a diff tomorrow. It's the extra blank lines in the
regression output thing that Claudio and others have remarked on. It
happens after every "(nnn rows)" line.
cheers
andrew
Bruce Momjian wrote:
>Andrew, can you illustrate to the group the exact difference in output?
>
>---------------------------------------------------------------------------
>
>Andrew Dunstan wrote:
>
>
>>I have tried very hard to work out why this patch works for the
>>regression tests in MINGW/MSys, but it doesn't make any sense why this
>>one call should add an extra blank line. Does anyone have any bright
>>ideas? I'm reluctant to say I think we should apply it until the problem
>>is understood and the behaviour explained. But it does appear to work.
>>
>>cheers
>>
>>andrew
>>
>>
>>
>>
>>
>>>>>>Index: print.c
>>>>>>===================================================================
>>>>>>RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/print.c,v
>>>>>>retrieving revision 1.46
>>>>>>diff -c -w -r1.46 print.c
>>>>>>*** print.c 24 Jan 2004 20:43:26 -0000 1.46
>>>>>>--- print.c 30 Apr 2004 16:44:46 -0000
>>>>>>***************
>>>>>>*** 388,394 ****
>>>>>>--- 388,396 ----
>>>>>> for (ptr = footers; *ptr; ptr++)
>>>>>> fprintf(fout, "%s\n", *ptr);
>>>>>>
>>>>>>+ #ifndef WIN32
>>>>>> fputc('\n', fout);
>>>>>>+ #endif
>>>>>>
>>>>>> /* clean up */
>>>>>> free(cell_w);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 7: don't forget to increase your free space map settings
>>
>>
>>
>
>
>
> I have tried very hard to work out why this patch works for the > regression tests in MINGW/MSys, but it doesn't make any sense why this > one call should add an extra blank line. Does anyone have any bright > ideas? I'm reluctant to say I think we should apply it until the problem > is understood and the behaviour explained. But it does appear to work. Perhaps it is a DOS line termination problem...0D/0A...this is the only thing I can think of. Merlin
Merlin Moncure writes: > Perhaps it is a DOS line termination problem...0D/0A...this > is the only thing I can think of. Good idea. There are a few places in the code with suspicious comments like the following from scan.c/l * Unix ones, we accept either \n or \r as a newline. A DOS-style \r\n * sequence will be seen as two successive newlines, but that doesn't cause * any problems. Comments that start with -- and extend to the next That looks like a possible suspect for sure. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
Claudio Natoli wrote: >Merlin Moncure writes: > > >>Perhaps it is a DOS line termination problem...0D/0A...this >>is the only thing I can think of. >> >> > >Good idea. There are a few places in the code with suspicious comments like >the following from scan.c/l > > * Unix ones, we accept either \n or \r as a newline. A DOS-style \r\n > * sequence will be seen as two successive newlines, but that doesn't cause > * any problems. Comments that start with -- and extend to the next > >That looks like a possible suspect for sure. > > > The CR/NL stuff was the first thing I thought of, of course. The scan stuff doesn't seem relevant though. My problem with the suggestion of this being a simple CR/NL translation issue is that in that case we should be seeing many more newlines than we are. Why does suppressing just this one work? That's what I find so puzzling. I'm currently rebuilding and looking into it more. cheers andrew