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

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