Обсуждение: port v7.0 to SGI-IRIX-6.5.7/64

Поиск
Список
Период
Сортировка

port v7.0 to SGI-IRIX-6.5.7/64

От
Murad Nayal
Дата:
I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX
6.5.7. I compiled to 64bit libraries. The problems I had were both due
errors in the configure script as well as postgres configuration files.

configure problems:
-------------------
1- the program that configure uses to test for namespace std is faulty.
I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of
interfaces/libpq++/pgconnection.h

2- configure badly guesses the type of the 3rd argument to accept(). it
decided it should be size_t (unsigned int on IRIX) while accept on IRIX
takes an int. postgres compiles, but accept never retrieves the IP
address of the connecting client (in StreamConnection() function in the
file backend/libpq/pqcomm.c). as a result no authentication can happen
and the postmaster refuses connections regardless of what is in
pg_hba.conf. the error message is usually something like

"no pg_hba.conf entry for host localhost user postgres database
template1"

here local host is just a default string and apparently will never match
anything in pg_hba.conf. to fix this i changed line 521 of
include/config.h
from:      #define SOCKET_SIZE_TYPE size_t
to:        #define SOCKET_SIZE_TYPE int

postgres problems
------------------
3- src/pl/tcl/Makefile has a bug. line 69 is
CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
that clobbers all CFLAGS included previously. as a result the include
directories, important to find tcl.h etc. will not be added to the
options and the compilation stops here complaining that it can't locate
tcl.h etc.
I just changed it to
CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)

4- I had to change line 8 of   interfaces/odbc/isqlext.h
  from     # include       <isql.h>
  to       # include       "isql.h"
to force the inclusion of the local isql.h


now my questions: While compiling, i noticed a lot of warnings about
pointers getting truncated etc. it seems that postgres assumes pointer
sizes to be 32 bits. so I suppose compiling for a 64bit platform can be
risky. Anyone have experience compiling postgres on a 64bit platform.

a lot of the regression tests also failed. some of these failures don't
seem to be trivial (some are trivial). I will paste below the overall
report of the regression testing. But what I would really love is for
someone to look at the my regression.diffs and kind of enlighten me to
the problems I should expect with this installation or (better still)
what to look at to fix the problems. I have not used postgres before and
am actually fairly green with databases in general so any help is most
appreciated.

if interested I could email you the diffs for the above changes.

Best Regards
Murad Nayal


configure command
-----------------
./configure --prefix=/local --with-includes=/local/include
--with-libraries=/local/lib --with-tcl --with-tclconfig=/local/lib
--with-tkconfig=/local/lib --with-perl --with-odbc --with-CC="cc -O2
-Xcpluscomm" --with-CXX="CC -O2" --with-x

regression results
------------------

gmake runtest
cc -O2 -Xcpluscomm -I../../include -I../../backend   -I/local/include
-U_NO_XOPEN4 -woff 1164,1171,1185,1195,1552 -Wl,-woff,15 -Wl,-woff,84
-I../../interfaces/libpq -I../../include    -c regress.c -o regress.o
ld -G -Bdynamic -shared -o regress.so regress.o
MULTIBYTE=;export MULTIBYTE; \
/bin/sh ./regress.sh mips-sgi-irix6.5 2>&1 | tee regress.out
=============== Notes...                              =================
postmaster must already be running for the regression tests to succeed.
The time zone is set to PST8PDT for these tests by the client frontend.
Please report any apparent problems to ports@postgresql.org
See regress/README for more information.

=============== dropping old regression database...   =================
DROP DATABASE
=============== creating new regression database...   =================
CREATE DATABASE
=============== installing languages...               =================
installing PL/pgSQL ..  ok
=============== running regression queries...         =================
boolean ..  ok
char ..  ok
name ..  ok
varchar ..  ok
text ..  ok
int2 ..  failed
int4 ..  failed
int8 ..  failed
oid ..  ok
float4 ..  ok
float8 ..  ok
numeric ..  ok
strings ..  failed
numerology ..  failed
point ..  ok
lseg ..  ok
box ..  ok
path ..  ok
polygon ..  ok
circle ..  ok
interval ..  ok
timestamp ..  ok
reltime ..  ok
tinterval ..  failed
inet ..  ok
comments ..  ok
oidjoins ..  failed
type_sanity ..  failed
opr_sanity ..  failed
abstime ..  failed
geometry ..  failed
horology ..  failed
create_function_1 ..  ./regress.sh[116]: sql/create_function_1.sql:
cannot open: No such file or directory
diff: expected/create_function_1.out: No such file or directory
diff: results/create_function_1.out: No such file or directory
ok
create_type ..  failed
create_table ..  ok
create_function_2 ..  ./regress.sh[116]: sql/create_function_2.sql:
cannot open: No such file or directory
diff: expected/create_function_2.out: No such file or directory
diff: results/create_function_2.out: No such file or directory
ok
copy ..  ./regress.sh[116]: sql/copy.sql: cannot open: No such file or
directory
diff: expected/copy.out: No such file or directory
diff: results/copy.out: No such file or directory
ok
constraints ..  ./regress.sh[116]: sql/constraints.sql: cannot open: No
such file or directory
diff: expected/constraints.out: No such file or directory
diff: results/constraints.out: No such file or directory
ok
triggers ..  failed
create_misc ..  ok
create_aggregate ..  ok
create_operator ..  failed
create_index ..  failed
create_view ..  failed
sanity_check ..  ok
errors ..  ok
select ..  failed
select_into ..  ok
select_distinct ..  failed
select_distinct_on ..  failed
select_implicit ..  ok
select_having ..  ok
subselect ..  ok
union ..  ok
case ..  ok
join ..  ok
aggregates ..  failed
transactions ..  failed
random ..  failed
portals ..  failed
arrays ..  ok
btree_index ..  failed
hash_index ..  failed
misc ..  ./regress.sh[116]: sql/misc.sql: cannot open: No such file or
directory
diff: expected/misc.out: No such file or directory
diff: results/misc.out: No such file or directory
ok
select_views ..  failed
alter_table ..  failed
portals_p2 ..  failed
rules ..  failed
foreign_key ..  ok
limit ..  failed
plpgsql ..  ok
temp ..  ok
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out

To run the optional big test(s) too, type 'make bigtest'
These big tests can take over an hour to complete
These actually are: numeric_big
rm regress.o





--
Murad Nayal M.D. Ph.D.
Department of Biochemistry and Molecular Biophysics
College of Physicians and Surgeons of Columbia University
630 West 168th Street. New York, NY 10032
Tel: 212-305-6884    Fax: 212-305-6926

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Tom Lane
Дата:
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> 1- the program that configure uses to test for namespace std is faulty.

That's not very helpful :-( --- what's wrong with it?

> 2- configure badly guesses the type of the 3rd argument to accept().

I have seen that happen on other platforms too; not clear how to fix it.
But as long as the guessed value is the right size it should work,
I would think --- unsigned int vs. int shouldn't make a difference.
Are you sure that that is the reason it wasn't working?

> 3- src/pl/tcl/Makefile has a bug. line 69 is
> CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
> that clobbers all CFLAGS included previously. as a result the include
> directories, important to find tcl.h etc. will not be added to the
> options and the compilation stops here complaining that it can't locate
> tcl.h etc.
> I just changed it to
> CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)

Good point, but that's no solution --- the reason that the makefile
isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be
built with a different compiler than Postgres is being built with.
The Tcl compiler may not like the other compiler's switches.  I guess
we could arrange to insert just the -I switches from your
--with-includes configuration command, however.

> 4- I had to change line 8 of   interfaces/odbc/isqlext.h
>   from     # include       <isql.h>
>   to       # include       "isql.h"
> to force the inclusion of the local isql.h

Good catch.

> now my questions: While compiling, i noticed a lot of warnings about
> pointers getting truncated etc. it seems that postgres assumes pointer
> sizes to be 32 bits. so I suppose compiling for a 64bit platform can be
> risky. Anyone have experience compiling postgres on a 64bit platform.

We do assume that "unsigned long" will hold a pointer; if that's not
true on IRIX then you're going to have troubles.  There are a number
of patches known to be needed on Alphas, which are planned for
integration into the standard distribution for 7.1 --- dunno if any
of them would help on your setup.

> a lot of the regression tests also failed. some of these failures don't
> seem to be trivial (some are trivial).

It looks like you neglected to run "make all" before "make runtest".
Try that and see if it gets better...

            regards, tom lane

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Bruce Momjian
Дата:
>
> I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX
> 6.5.7. I compiled to 64bit libraries. The problems I had were both due
> errors in the configure script as well as postgres configuration files.
>
> configure problems:
> -------------------
> 1- the program that configure uses to test for namespace std is faulty.
> I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of
> interfaces/libpq++/pgconnection.h

Can you suggest a test that does work on Irix?

>
> 2- configure badly guesses the type of the 3rd argument to accept(). it
> decided it should be size_t (unsigned int on IRIX) while accept on IRIX
> takes an int. postgres compiles, but accept never retrieves the IP
> address of the connecting client (in StreamConnection() function in the
> file backend/libpq/pqcomm.c). as a result no authentication can happen
> and the postmaster refuses connections regardless of what is in
> pg_hba.conf. the error message is usually something like
>
> "no pg_hba.conf entry for host localhost user postgres database
> template1"
>
> here local host is just a default string and apparently will never match
> anything in pg_hba.conf. to fix this i changed line 521 of
> include/config.h
> from:      #define SOCKET_SIZE_TYPE size_t
> to:        #define SOCKET_SIZE_TYPE int

Again, a suggested change?

>
> postgres problems
> ------------------
> 3- src/pl/tcl/Makefile has a bug. line 69 is
> CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
> that clobbers all CFLAGS included previously. as a result the include
> directories, important to find tcl.h etc. will not be added to the
> options and the compilation stops here complaining that it can't locate
> tcl.h etc.
> I just changed it to
> CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)

Changed.

>
> 4- I had to change line 8 of   interfaces/odbc/isqlext.h
>   from     # include       <isql.h>
>   to       # include       "isql.h"
> to force the inclusion of the local isql.h

Changed.  Will appear in 7.0.1.


--
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [PORTS] Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Bruce Momjian
Дата:
> > 3- src/pl/tcl/Makefile has a bug. line 69 is
> > CFLAGS= $(TCL_CFLAGS_OPTIMIZE)
> > that clobbers all CFLAGS included previously. as a result the include
> > directories, important to find tcl.h etc. will not be added to the
> > options and the compilation stops here complaining that it can't locate
> > tcl.h etc.
> > I just changed it to
> > CFLAGS+= $(TCL_CFLAGS_OPTIMIZE)
>
> Good point, but that's no solution --- the reason that the makefile
> isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be
> built with a different compiler than Postgres is being built with.
> The Tcl compiler may not like the other compiler's switches.  I guess
> we could arrange to insert just the -I switches from your
> --with-includes configuration command, however.

Tom, do you want his verion in Makefile, or the original?

--
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [PORTS] Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Tom Lane
Дата:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Good point, but that's no solution --- the reason that the makefile
>> isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be
>> built with a different compiler than Postgres is being built with.
>> The Tcl compiler may not like the other compiler's switches.  I guess
>> we could arrange to insert just the -I switches from your
>> --with-includes configuration command, however.

> Tom, do you want his verion in Makefile, or the original?

I'm working on it now --- need to fix configure to export a list of
just the -I switches, so we can include those into the pltcl build.

plperl may have the same problem, haven't looked yet.

There is a potential problem in this area that I've actually seen
happen, but don't know a way around: the two compilers may have
different default search paths.  For example, on my system gcc includes
/usr/local/include in its default search path, but the system cc does
not.  So, if you've built Tcl with system cc, and installed it in
/usr/local, and then try to build Postgres with gcc and --with-tcl,
everything goes fine until you get to pltcl, whereupon it falls over
because pltcl will be built with cc and cc doesn't find tcl.h.
That will still happen with this fix.  The only way to build that
configuration successfully is to explicitly say
"--with-includes=/usr/local/include --with-libs=/usr/local/lib".

Arguably this is a bug in Tcl's tclConfig.sh, since it probably ought to
put "-I/usr/local/include" into its own CFLAGS settings when it's been
built that way ... but it doesn't ...

I don't have an answer to solving that problem automatically,
but I thought it'd be good to mention it for the archives.

            regards, tom lane

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Tom Lane
Дата:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> 2- configure badly guesses the type of the 3rd argument to accept(). it
>> decided it should be size_t (unsigned int on IRIX) while accept on IRIX
>> takes an int.

> Again, a suggested change?

This is something that's been bugging me for a while; the problem on
most platforms is that int vs unsigned int parameter will only draw a
warning from the compiler, and autoconf's TRY_COMPILE macro is only able
to detect outright errors.

I looked at the standard Autoconf macros just now, and found an example
that may give us the right solution: instead of trying to see whether
a call of accept with "int" or "unsigned int" parameter works, include
<sys/socket.h> and then write an "extern" declaration for accept with
the parameters we think it should have.  This relies on the hope that
if the compiler sees two declarations for accept with different
parameter lists, it'll generate an error and not just a warning.

It seems like that should work at least as well, maybe better, as what
we're doing now --- but it's not the kind of change that I want to shove
into 7.0.1 with no beta testing!  Probably we should introduce it early
in the 7.1 cycle instead, and see if anyone reports problems.

            regards, tom lane

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Murad Nayal
Дата:
Bruce Momjian wrote:
>
> >
> > I managed to compile (and sort of run) postgres 7.0 to SGI running IRIX
> > 6.5.7. I compiled to 64bit libraries. The problems I had were both due
> > errors in the configure script as well as postgres configuration files.
> >
> > configure problems:
> > -------------------
> > 1- the program that configure uses to test for namespace std is faulty.
> > I had to manually add #define HAVE_NAMESPACE_STD 1 to the top of
> > interfaces/libpq++/pgconnection.h
>
> Can you suggest a test that does work on Irix?
>

the current test is:

#line 1680 "configure"
#include "confdefs.h"
#include <stdio.h>
#include <stdlib.h>
using namespace std;

int main() {

; return 0; }

it fails with the message:

"configure", line 1683: error(3173): name must be a namespace name
  using namespace std;

you just need to add a header file that contains elements of the C++
standard library defined in std. not all C++ standard library that comes
with the SGI C++ compiler are in defined in std. for example iostream
stuff are not in std. however string is. so just include the string
header file in the program. This compiles fine with CC:

#line 1680 "configure"
#include "confdefs.h"
#include <stdio.h>
#include <stdlib.h>
#include <string>
using namespace std;

int main() {

; return 0; }

the SGI compiler puts the std library in header files that don't end in
".h". same header file ending in ".h" will have declarations in the
global name space.

Regards

--
Murad Nayal M.D. Ph.D.
Department of Biochemistry and Molecular Biophysics
College of Physicians and Surgeons of Columbia University
630 West 168th Street. New York, NY 10032
Tel: 212-305-6884    Fax: 212-305-6926

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Murad Nayal
Дата:
Tom Lane wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> 2- configure badly guesses the type of the 3rd argument to accept(). it
> >> decided it should be size_t (unsigned int on IRIX) while accept on IRIX
> >> takes an int.
>
> > Again, a suggested change?
>
> This is something that's been bugging me for a while; the problem on
> most platforms is that int vs unsigned int parameter will only draw a
> warning from the compiler, and autoconf's TRY_COMPILE macro is only able
> to detect outright errors.
>
> I looked at the standard Autoconf macros just now, and found an example
> that may give us the right solution: instead of trying to see whether
> a call of accept with "int" or "unsigned int" parameter works, include
> <sys/socket.h> and then write an "extern" declaration for accept with
> the parameters we think it should have.  This relies on the hope that
> if the compiler sees two declarations for accept with different
> parameter lists, it'll generate an error and not just a warning.

sys/socket is already included in the test program. and yet all I get
from the cc compiler is a warning!!! But here is a bit of trivia that I
found. the CC compiler (C++ on SGI) won't take it and will generate an
error. I am not sure obviously if this is to be expected of other C++
compilers. This particular warning message on my compiler has the number
1164. you can turn warning messages to error conditions using the flag
-diag_error message_number. So while cc conftest.c in this case
generates a warning. cc -diag_error 1164 conftest.c will generate an
error. Again I don't know if this feature is common in other compilers.

Murad



--
Murad Nayal M.D. Ph.D.
Department of Biochemistry and Molecular Biophysics
College of Physicians and Surgeons of Columbia University
630 West 168th Street. New York, NY 10032
Tel: 212-305-6884    Fax: 212-305-6926

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Murad Nayal
Дата:
Tom Lane wrote:
>
> Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> > 1- the program that configure uses to test for namespace std is faulty.
>
> That's not very helpful :-( --- what's wrong with it?
>
> > 2- configure badly guesses the type of the 3rd argument to accept().
>
> I have seen that happen on other platforms too; not clear how to fix it.
> But as long as the guessed value is the right size it should work,
> I would think --- unsigned int vs. int shouldn't make a difference.
> Are you sure that that is the reason it wasn't working?
>

I am actually pretty sure that giving accept a size_t addrlen (in this
case) is causing accept to not copy the client address over (at least
not copy it to the right place!). I was a little bit inaccurate in my
statement earlier though. size_t is unsigned int when compiling in 32bit
mode. however it seems to be unsigned long (8 bytes) when compiling in
64bit mode, while int is still 4 bytes. so that seems consistent with
what you said.

I was trying to compile postgres in 64 because I would like to integrate
it with the rest of my libraries which I usually compile in 64bit mode.
I suppose I only need the frontend to be binary compatible with my code
(libpq?) but I can only imagine the hassle I could get into trying to
compile the front end in 64 and the backend separately in n32. I am
going to repeat the regression tests just to make sure I used gmake all
in regress and will report back.


Regards



--
Murad Nayal M.D. Ph.D.
Department of Biochemistry and Molecular Biophysics
College of Physicians and Surgeons of Columbia University
630 West 168th Street. New York, NY 10032
Tel: 212-305-6884    Fax: 212-305-6926

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Tom Lane
Дата:
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> I was a little bit inaccurate in my
> statement earlier though. size_t is unsigned int when compiling in 32bit
> mode. however it seems to be unsigned long (8 bytes) when compiling in
> 64bit mode, while int is still 4 bytes.

OK, in that case I'd believe it's a critical issue.

I think the conflicting-declarations trick I mentioned earlier will let
us build a more reliable configure test for this, but as I said I don't
want to risk shoving it into 7.0.* --- this is the sort of thing that
you can't trust until it's been through some beta testing on a variety
of platforms.  We'll put it in 7.1 and see what happens.  In the
meantime you'll have to patch config.h by hand...

            regards, tom lane

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Tom Lane
Дата:
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> you just need to add a header file that contains elements of the C++
> standard library defined in std. not all C++ standard library that comes
> with the SGI C++ compiler are in defined in std. for example iostream
> stuff are not in std. however string is. so just include the string
> header file in the program.

You realize, of course, that we don't want to depend on <string>
being there either ;-)

But I suppose we could swap the order of the tests, and then
include <string> into the namespace test if we've found it.
Will do...

            regards, tom lane

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Murad Nayal
Дата:
>
> It looks like you neglected to run "make all" before "make runtest".
> Try that and see if it gets better...

ok, you were right. apparently on my last cycle of gmake clean/gmake all
I dropped the gmake all. On a brand new installation (it is amazing how
fast these things go once you figure out all the necessary tweaks :-) )
the testing output does get better. Still I am getting a lot of fails
and most of them seem nontrivial. regress.out is below.

I ran the sequential tests since I actually needed to insert a line in
pg_hba.conf to allow my host to connect: the line
host         all         127.0.0.1     255.255.255.255   trust
wasn't enough for some reason, I had to specify my IP address in an
additional line for the authentication to work.
host         all         156.111.96.29 255.255.255.255   trust
hence, I had to run the postmaster on the modified configuration before
the tests.

anyway, please let me know if failing of any of these tests is
particularly ominous. the regressions.diffs, the postmaster output or
the gmake output are also available if anybody is interested.

Thanks

cat regress.out
=============== Notes...                              =================
postmaster must already be running for the regression tests to succeed.
The time zone is set to PST8PDT for these tests by the client frontend.
Please report any apparent problems to ports@postgresql.org
See regress/README for more information.

=============== dropping old regression database...   =================
ERROR:  DROP DATABASE: Database "regression" does not exist
dropdb: database removal failed
=============== creating new regression database...   =================
CREATE DATABASE
=============== installing languages...               =================
installing PL/pgSQL ..  ok
=============== running regression queries...         =================
boolean ..  ok
char ..  ok
name ..  ok
varchar ..  ok
text ..  ok
int2 ..  failed
int4 ..  failed
int8 ..  failed
oid ..  ok
float4 ..  ok
float8 ..  ok
numeric ..  ok
strings ..  failed
numerology ..  failed
point ..  ok
lseg ..  ok
box ..  ok
path ..  ok
polygon ..  ok
circle ..  ok
interval ..  ok
timestamp ..  ok
reltime ..  ok
tinterval ..  failed
inet ..  ok
comments ..  ok
oidjoins ..  failed
type_sanity ..  failed
opr_sanity ..  failed
abstime ..  failed
geometry ..  failed
horology ..  failed
create_function_1 ..  ok
create_type ..  ok
create_table ..  ok
create_function_2 ..  ok
copy ..  ok
constraints ..  ok
triggers ..  ok
create_misc ..  ok
create_aggregate ..  ok
create_operator ..  ok
create_index ..  ok
create_view ..  ok
sanity_check ..  ok
errors ..  ok
select ..  ok
select_into ..  ok
select_distinct ..  ok
select_distinct_on ..  ok
select_implicit ..  ok
select_having ..  ok
subselect ..  ok
union ..  ok
case ..  ok
join ..  ok
aggregates ..  ok
transactions ..  ok
random ..  ok
portals ..  ok
arrays ..  ok
btree_index ..  ok
hash_index ..  ok
misc ..  ok
select_views ..  ok
alter_table ..  ok
portals_p2 ..  ok
rules ..  failed
foreign_key ..  ok
limit ..  ok
plpgsql ..  ok
temp ..  ok


--
Murad Nayal M.D. Ph.D.
Department of Biochemistry and Molecular Biophysics
College of Physicians and Surgeons of Columbia University
630 West 168th Street. New York, NY 10032
Tel: 212-305-6884    Fax: 212-305-6926

Re: port v7.0 to SGI-IRIX-6.5.7/64

От
Tom Lane
Дата:
Murad Nayal <murad@godel.bioc.columbia.edu> writes:
> the testing output does get better. Still I am getting a lot of fails
> and most of them seem nontrivial.

I agree.  Hard to tell with this level of detail, but you show many
failures in tests that aren't particularly platform-sensitive.
I think there are some real bugs to be worked out...

            regards, tom lane