Thread: Failures with windows port

Failures with windows port

From
Shridhar Daithankar
Date:
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.

  Shridhar


parallel group (13 tests):  text varchar oid char name float4 int2 boolean int8 int4 float8 bit numeric
     boolean              ... FAILED
     char                 ... FAILED
     name                 ... FAILED
     varchar              ... FAILED
     text                 ... FAILED
     int2                 ... FAILED
     int4                 ... FAILED
     int8                 ... FAILED
     oid                  ... FAILED
     float4               ... FAILED
     float8               ... FAILED
     bit                  ... FAILED
     numeric              ... FAILED
test strings              ... FAILED
test numerology           ... FAILED
parallel group (20 tests):  lseg path time timetz circle comments reltime abstime point tinterval polygon box inet
intervaltimestamp timestamptz date type_sanity oidjoins opr_sanity 
     point                ... FAILED
     lseg                 ... FAILED
     box                  ... FAILED
     path                 ... FAILED
     polygon              ... FAILED
     circle               ... FAILED
     date                 ... FAILED
     time                 ... FAILED
     timetz               ... FAILED
     timestamp            ... FAILED
     timestamptz          ... FAILED
     interval             ... FAILED
     abstime              ... FAILED
     reltime              ... FAILED
     tinterval            ... FAILED
     inet                 ... FAILED
     comments             ... FAILED
     oidjoins             ... FAILED
     type_sanity          ... FAILED
     opr_sanity           ... FAILED
test geometry             ... FAILED
test horology             ... FAILED
test insert               ... FAILED
test create_function_1    ... ok
test create_type          ... FAILED
test create_table         ... ok
test create_function_2    ... ok
test copy                 ... ok
parallel group (7 tests):  create_aggregate create_operator triggers constraints vacuum inherit create_misc
     constraints          ... FAILED
     triggers             ... FAILED
     create_misc          ... ok
     create_aggregate     ... ok
     create_operator      ... ok
     inherit              ... FAILED
     vacuum               ... FAILED
parallel group (2 tests):  create_view create_index
     create_index         ... FAILED
     create_view          ... FAILED
test sanity_check         ... FAILED
test errors               ... FAILED
test select               ... FAILED
parallel group (18 tests):  select_into select_having update transactions namespace case select_implicit
select_distinct_onarrays union select_distinct random portals join aggregates hash_index btree_index subselect 
     select_into          ... ok
     select_distinct      ... FAILED
     select_distinct_on   ... FAILED
     select_implicit      ... FAILED
     select_having        ... FAILED
     subselect            ... FAILED
     union                ... FAILED
     case                 ... FAILED
     join                 ... FAILED
     aggregates           ... FAILED
     transactions         ... FAILED
     random               ... failed (ignored)
     portals              ... FAILED
     arrays               ... FAILED
     btree_index          ... FAILED
     hash_index           ... FAILED
     update               ... FAILED
     namespace            ... FAILED
test privileges           ... FAILED
test misc                 ... FAILED
parallel group (5 tests):  portals_p2 cluster foreign_key rules select_views
     select_views         ... FAILED
     portals_p2           ... FAILED
     rules                ... FAILED
     foreign_key          ... FAILED
     cluster              ... FAILED
parallel group (14 tests):  copy2 truncate temp sequence rowtypes domain polymorphism rangefuncs limit plpgsql prepare
conversionwithout_oid alter_table 
     limit                ... FAILED
     plpgsql              ... FAILED
     copy2                ... FAILED
     temp                 ... FAILED
     domain               ... FAILED
     rangefuncs           ... FAILED
     prepare              ... FAILED
     without_oid          ... FAILED
     conversion           ... FAILED
     truncate             ... FAILED
     alter_table          ... FAILED
     sequence             ... FAILED
     polymorphism         ... FAILED
     rowtypes             ... FAILED
test stats                ... FAILED

Re: Failures with windows port

From
Andrew Dunstan
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Shridhar Daithankar
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Bruce Momjian
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Shridhar Daithankar
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Bruce Momjian
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Shridhar Daithankar
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Andrew Dunstan
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Shridhar Daithankar
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Bruce Momjian
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Andrew Dunstan
Date:
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

Re: [pgsql-hackers-win32] Failures with windows port

From
Andrew Dunstan
Date:
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