Thread: AIX 4.2.1 regression test
Hi, AIX 4.2.1 regression tests are ok :-) int2 .. failed other errmsg (ok) int4 .. failed other errmsg (ok) float8 .. failed has correct output / expected is wrong (ok) geometry .. failed rounding diffs (ok) abstime .. failed PDT instead of PST in some rows, 1h difference (ok) tinterval .. failed --"-- horology .. failed --"-- inet .. failed expected/inet.out is incorrect (ok, but please remake) rules .. failed other sort order in select * from rtest_admin (guess ok) It would need only the following modifikations to current CVS: remove file src/makefiles/Makefile.aix4no harm because it is not used (it does not work 100% because it won't resolve variablesfrompostgres main executable, therefore the postgres.imp is still needed) .alternatively I could try to do a newone modify configure test for cpp stdincurrently does xlc -E and fails to notice, that it does not work hand made libplpgsql.sothe command was: ld -H512 -bM:SRE -bI:/usr/postgres/lib/postgres.imp -bexpall -o libplpgsql.so.1.0\ pl_comp.o pl_exec.o pl_funcs.o pl_handler.o pl_parse.o -lcthe -bexpall makes it easier, but is newsince AIX 4.2, so those with 3.2 or 4.1 still need to do the .exp stuff cheers :-) Andreas
> AIX 4.2.1 regression tests are ok :-) Great. Will mark ya' down... > inet .. failed expected/inet.out is incorrect (ok, but please remake) D'Arcy/Paul/inet gang: Could you look at this and see if the inet.out is incorrect for your platforms too? I just took the results/inet.out, inspected it for gross errors (without knowing what I'm looking for) and put it in as the expected result. Don't know what might be wrong with it. > rules .. failed other sort order in select * from rtest_admin (guess ok) I think HPUX sees this too; it depends on the implementation of qsort() on your platform. > modify configure test for cpp stdin > currently does xlc -E and fails to notice, that it does not work I'm not sure how easy it will be, or if we need to be frozen for this release. Should be a patch if it doesn't make it into the main v6.4. You've already made a suggestion on what to look for, right? I'm recalling that you had some discussion on the list about that already. - Tom
Andreas Zeugswetter <andreas.zeugswetter@telecom.at> writes: > AIX 4.2.1 regression tests are ok :-) > rules .. failed other sort order in select * from rtest_admin (guess ok) Ah-hah, so HPUX is not the only platform where qsort chooses to output those tuples in the other order. I feel better now ;-) I will go ahead and modify the rules test to do an "order by" in the select * from rtest_admin command, so that it generates predictable results. > modify configure test for cpp stdin > currently does xlc -E and fails to notice, that it does not work I think we have two choices here: 1. Try to improve configure's test for cpp-from-stdin some more, and add to it the idea that it might have to fall back to calling /lib/cpp directly if neither "$(CPP)" nor "$(CPP) -" work for reading from stdin. 2. Rewrite the shell scripts that are using this feature so that they don't need cpp-from-stdin, but just use a temporary file and plain $(CPP). Then we can forget about testing for it in configure. A quick "glimpse" shows there are only two shell scripts using $(CPPSTDIN), so I think choice #2 is the way to go. At this point in the schedule, we need a high-probability-of-success fix, and tweaking an autoconf test is never a high-probability affair until you've actually run it on a lot of platforms. Hacking the scripts might be ugly, but it will work. regards, tom lane
> > AIX 4.2.1 regression tests are ok :-) > > rules .. failed > Ah-hah, so HPUX is not the only platform where qsort chooses to output > those tuples in the other order. I feel better now ;-) Don't feel too good. There is a reason AIX is pronounced "aches" :) > > modify configure test for cpp stdin > 2. Rewrite the shell scripts that are using this feature so that they > don't need cpp-from-stdin, but just use a temporary file and plain > $(CPP). Then we can forget about testing for it in configure. > A quick "glimpse" shows there are only two shell scripts using > $(CPPSTDIN), so I think choice #2 is the way to go. I agree. Those two scripts use temporary files for other stages of their processing, so it isn't a change from what they already do. I was tempted to do that a month ago when I first ran across the problem of the hardcoded cpp references. Are you going to try to do it now, or should we wait for v6.4.1? I would think that it has a high probability of success, with testing from just one or two people.
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: > I agree. Those two scripts use temporary files for other stages of their > processing, so it isn't a change from what they already do. I was > tempted to do that a month ago when I first ran across the problem of > the hardcoded cpp references. Are you going to try to do it now, or > should we wait for v6.4.1? I would think that it has a high probability > of success, with testing from just one or two people. I was planning to fix it now, unless Marc threatens to break my thumbs. Build failures are a sufficiently important problem that I think we oughta fix them ... and while this has only been reported on AIX, we don't know for sure that it won't happen anywhere else. Besides, I think Marc is gonna be too busy breaking Bruce's thumbs to worry about me ;-). regards, tom lane
Thus spake Thomas G. Lockhart > > inet .. failed expected/inet.out is incorrect (ok, but please remake) > > D'Arcy/Paul/inet gang: Could you look at this and see if the inet.out is > incorrect for your platforms too? I just took the results/inet.out, > inspected it for gross errors (without knowing what I'm looking for) and > put it in as the expected result. Don't know what might be wrong with > it. As discussed in irc, there seems to be a missing patch. I resent it to Bruce directly and he applied it. Please rerun the queries and replace the expected output. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.