Failures with windows port

Shridhar Daithankar wrote:

Hi,

I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.

I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./configure;make procedure after installing mingw.

We need more information. In particular, we would need to know

. what version of Windows, Mingw, MSys
. what is in your regression.diff (if you send it, you should probably
zip it up first).

cheers

andrew

Andrew Dunstan wrote:

Shridhar Daithankar wrote:

Hi,

I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.

I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./configure;make procedure after installing mingw.

We need more information. In particular, we would need to know

. what version of Windows, Mingw, MSys

Windows 2000 Professional, MingW 3.1.0.1, MSys 1.0.10

. what is in your regression.diff (if you send it, you should probably
zip it up first).

http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out

HTH

Shridhar

Shridhar Daithankar wrote:

Andrew Dunstan wrote:

Shridhar Daithankar wrote:

Hi,

I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.

I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./configure;make procedure after installing mingw.

We need more information. In particular, we would need to know

. what version of Windows, Mingw, MSys

Windows 2000 Professional, MingW 3.1.0.1, MSys 1.0.10

. what is in your regression.diff (if you send it, you should probably
zip it up first).

http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out

Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.

-- 
  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 Momjian wrote:

http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out

Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.

ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz

It is timestamped at 6/7/2004, 8:09 AM.

Anyways, I will install flex and bison and use CVS. I was just being lazy to opt
for a snapshot..

Shridhar

Shridhar Daithankar wrote:

Bruce Momjian wrote:

http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out

Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.

ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz

It is timestamped at 6/7/2004, 8:09 AM.

Anyways, I will install flex and bison and use CVS. I was just being lazy to opt
for a snapshot..

That is certainly new enough. We added a MinGW workaround to fix a
problem with extra newlines coming from psql, but you might have a
configuration that doesn't need the workaround.

Do you need this line in psql/print.c?

#ifndef __MINGW32__
/* for some reason MinGW outputs an extra newline, so this supresses it */
fputc('\n', fout);
#endif

That might be the cause of your problem? If you have it try removing it and recompile.

-- 
  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 Momjian wrote:

Shridhar Daithankar wrote:

Bruce Momjian wrote:

http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out

Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.

ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz

It is timestamped at 6/7/2004, 8:09 AM.

Anyways, I will install flex and bison and use CVS. I was just being lazy to opt
for a snapshot..

That is certainly new enough. We added a MinGW workaround to fix a
problem with extra newlines coming from psql, but you might have a
configuration that doesn't need the workaround.

Do you need this line in psql/print.c?

#ifndef __MINGW32__
/* for some reason MinGW outputs an extra newline, so this supresses it */
fputc('\n', fout);
#endif

That might be the cause of your problem? If you have it try removing it and recompile.

No it is not. A quick #if 0...#endif around it and recompile produced 87
failures out of 95 test, one being ignored.

Leaving it for a full build as I am calling it a day. Will give it another go
tomorrow morning..

Shridhar

Shridhar Daithankar wrote:

Bruce Momjian wrote:

Shridhar Daithankar wrote:

Bruce Momjian wrote:

http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out

Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.

ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz

It is timestamped at 6/7/2004, 8:09 AM.

Anyways, I will install flex and bison and use CVS. I was just being
lazy to opt for a snapshot..

That is certainly new enough. We added a MinGW workaround to fix a
problem with extra newlines coming from psql, but you might have a
configuration that doesn't need the workaround.

Do you need this line in psql/print.c?

#ifndef __MINGW32__
/* for some reason MinGW outputs an extra newline, so this
supresses it */
fputc('\n', fout);
#endif

That might be the cause of your problem? If you have it try removing
it and recompile.

No it is not. A quick #if 0...#endif around it and recompile produced
87 failures out of 95 test, one being ignored.

Leaving it for a full build as I am calling it a day. Will give it
another go tomorrow morning..

What you would need to test is not #ifdefing the whole thing out -
rather you would need to enable the fputc by removing the #ifndef and
#endif lines.

cheers

andrew

Shridhar Daithankar wrote:

Shridhar Daithankar wrote:

I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.

I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./configure;make procedure after installing mingw.

Windows 2000 Professional, MingW 3.1.0.1, MSys 1.0.10

Is MSys 1.0.10 supported already? I thought 1.0.9 was still the
recommended version.

Jochem

Jochem van Dieten wrote:

Shridhar Daithankar wrote:

Shridhar Daithankar wrote:

I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.

I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./configure;make procedure after installing mingw.

Windows 2000 Professional, MingW 3.1.0.1, MSys 1.0.10

Is MSys 1.0.10 supported already? I thought 1.0.9 was still the
recommended version.

Well, 1.0.10 has already been released, so we have better support it or
find out why it doesn't work.

-- 
  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 Momjian wrote:

Jochem van Dieten wrote:

Shridhar Daithankar wrote:

Shridhar Daithankar wrote:

I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.

I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./configure;make procedure after installing mingw.

Windows 2000 Professional, MingW 3.1.0.1, MSys 1.0.10

Is MSys 1.0.10 supported already? I thought 1.0.9 was still the
recommended version.

Well, 1.0.10 has already been released, so we have better support it or
find out why it doesn't work.

Shridar's appears to be the exact setup I am using.

I have just done a fresh cvs checkout, followed by "./configure
--without-zlib; make check" and got 94 of 95 tests passing (still
waiting for the alternative join result I submitted weeks ago to be
added to CVS).

Maybe he is running the check from cygwin, as we used to advise people
to do? There is no need to do that any more - you can run the regression
checks from MSys.

Other notes:

There is a bug in the link check code in configure.in - I will submit a
patch shortly.

I have also noticed some compiler warnings that we should clean up.

cheers

andrew

Andrew Dunstan wrote:

Shridhar Daithankar wrote:

Leaving it for a full build as I am calling it a day. Will give it
another go tomorrow morning..

What you would need to test is not #ifdefing the whole thing out -
rather you would need to enable the fputc by removing the #ifndef and
#endif lines.

Hmm.. good.. It worked. 1 out of 95 tests failed. Join is the test that is failed.

Now I can go about installing and playing with it. I should use CVS in future
though..

And BTW, I was not running the regression in a cygwin shell. It was a msys shell
only. I am thinking of knowcking off cygwin in favour of msys. But I don't find
CVS with msys.. I need to find a commandline cvs for daily use. WinCVS is just
too much GUI for my taste..

Thanks again..

Shridhar

-----Original Message-----
From: pgsql-hackers-win32-owner@postgresql.org
[mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf
Of Shridhar Daithankar
Sent: 08 June 2004 08:34
To: Andrew Dunstan
Cc: PostgreSQL-development; pgsql-hackers-win32@postgresql.org
Subject: Re: [pgsql-hackers-win32] [HACKERS] Failures with
windows port

And BTW, I was not running the regression in a cygwin shell.
It was a msys shell
only. I am thinking of knowcking off cygwin in favour of
msys. But I don't find
CVS with msys.. I need to find a commandline cvs for daily
use. WinCVS is just
too much GUI for my taste..

If you find it, let me know please - I have the same problem :-) Stock
cvs won't compile on msys :-(

Regards, Dave.

And BTW, I was not running the regression in a cygwin shell.
It was a msys shell
only. I am thinking of knowcking off cygwin in favour of

msys. But I

don't find CVS with msys.. I need to find a commandline cvs

for daily

use. WinCVS is just too much GUI for my taste..

If you find it, let me know please - I have the same problem
:-) Stock cvs won't compile on msys :-(

I use cvsnt (www.cvsnt.org). Works great from both "standard console"
and msys console.
(Or tortoise (www.tortoisecvs.org) when I want a GUI, but it's basically
a shell over cvsnt)

//Magnus

Shridhar Daithankar wrote:

Andrew Dunstan wrote:

Shridhar Daithankar wrote:

Leaving it for a full build as I am calling it a day. Will give it
another go tomorrow morning..

What you would need to test is not #ifdefing the whole thing out -
rather you would need to enable the fputc by removing the #ifndef and
#endif lines.

Hmm.. good.. It worked. 1 out of 95 tests failed. Join is the test that is failed.

Now I can go about installing and playing with it. I should use CVS in future
though..

And BTW, I was not running the regression in a cygwin shell. It was a msys shell
only. ....

Can someone confirm that the newer 1.10 MinGW doesn't need the psql
print.c newline hack? If so, we can do a version test in that area and
mark it down as a mingw version-specific bug.

-- 
  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 Momjian wrote:

Shridhar Daithankar wrote:

Andrew Dunstan wrote:

Shridhar Daithankar wrote:

Leaving it for a full build as I am calling it a day. Will give it
another go tomorrow morning..

What you would need to test is not #ifdefing the whole thing out -
rather you would need to enable the fputc by removing the #ifndef and
#endif lines.

Hmm.. good.. It worked. 1 out of 95 tests failed. Join is the test that is failed.

Now I can go about installing and playing with it. I should use CVS in future
though..

And BTW, I was not running the regression in a cygwin shell. It was a msys shell
only. ....

Can someone confirm that the newer 1.10 MinGW doesn't need the psql
print.c newline hack? If so, we can do a version test in that area and
mark it down as a mingw version-specific bug.

I assume you mean MSys 1.0.10 - I have that plus MinGW 3.1.0-1 these are
the latest releases that are not "candidates"

The fix seems needed on mine. Still investigating.

cheers

andrew

I wrote:

Bruce Momjian wrote:

Can someone confirm that the newer 1.10 MinGW doesn't need the psql
print.c newline hack? If so, we can do a version test in that area and
mark it down as a mingw version-specific bug.

I assume you mean MSys 1.0.10 - I have that plus MinGW 3.1.0-1 these
are the latest releases that are not "candidates"

The fix seems needed on mine. Still investigating.

I have pretty much eliminated the possibility that some CVS nastiness
with line endings could cause the problem - I tested with a checkout via
a cvs that translates line endings, one that does not (cygwin's), and
the nightly snapshot. All gave clean results with the fix in, dirty with
it removed. Presumably it must be a function of either the OS or the
MSys/MinGW setup.

My System:
W2K
5.00.2195
SP4
x86 Family 6 model 8
MSys 1.0.10
MinGW 3.1.0-1

Command used to test: "./configure --without-zlib; make check"

At this stage I have no clue as to what systems might/might not need the
fix.

cheers

andrew