Thread: Failures with windows port
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
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
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
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