Re: Bug #612: PostgreSQL 7.2 does not build according to

> A lot of this looks like problems with configure using the wrong cpp
> to do C preprocessor tests.  In particular the syntax errors in the

I tried setting it manually and that fixed it.  I couldn't get configure
to work using either method of getting at MIPSpro's preprocessor (/lib/cpp
and /usr/bin/cc -E should both work).  So, I told it to use GCC's
preprocessor, and all was well.

> and I wonder whether /lib/cpp is actually equivalent to /usr/bin/cc's
> preprocessing.  Does /usr/bin/cc accept a -E switch?  If so, why didn't
> configure use that?  (Do you maybe have CPP=/lib/cpp in your
> environment?)

/lib/cpp is the proper preprocessor for MIPSpro.  However, it just didn't
seem to generate things properly.  For example, it absolutely failed to
generate the table mapping function-names to IDs.

> > checking whether the C compiler (/usr/bin/cc -O3
-I/usr/freeware/include -L/usr/freeware/lib32 -L/usr/lib32) works... yes

That's in my environment.  It saves me from having to include them every
time, as all the vendor-supplied stuff is in /usr, and all the GNU and
otherwise-freeware is in /usr/freeware.  It's an IRIX convention.

> Bottom line is that I suspect configure is being misled by some of
> your environment settings.  But another possibility is that
> src/makefiles/Makefile.irix5 is doing something inappropriate.
> In particular I wonder why it has
>     override CPPFLAGS += -U_NO_XOPEN4
> Is this (still) appropriate for IRIX?  If so, perhaps it needs to be
> done in src/template/irix5 instead (so that configure will see it)?

I don't -think- it's still appropriate, but I don't know.  Thanks to
Robert E. Bruccoleri, I got it working.  I made a few modifications to the
script he gave me.  Here's mine:

#!/bin/ksh -x

rm -f config.cache config.status

export SGI_ABI=-n32
export CC=/usr/bin/cc
export CXX=/usr/bin/CC
cat >config.cache <<EOF
ac_cv_lib_nsl_main=${ac_cv_lib_nsl_main='no'}
ac_cv_prog_CPP=${ac_cv_prog_CPP='/usr/freeware/bin/gcc -E'}
ac_cv_prog_gcc=${ac_cv_prog_gcc=no}
ac_cv_prog_perl=${ac_cv_prog_perl=/usr/freeware/bin/perl}
EOF
gmake clean
CC="cc -n32" \
AWK=/usr/freeware/bin/gawk \
INSTALL=/usr/src/postgresql-7.2/config/install-sh \
LDFLAGS="-rpath /usr/freeware/lib" \
./configure --prefix=/usr/db/postgres \
        --enable-hba \
        --with-pgport=5432 \
        --disable-locale \
        --enable-cassert \
        --with-template=irix5 \
        --with-includes="/usr/freeware/include
/usr/freeware/include/readline" \
        --with-libs=/usr/freeware/lib \
        --without-CXX \
        --with-maxbackends=128 \
        --enable-debug \
        --enable-syslog \
        --with-tcl \
        --with-tclconfig=/usr/freeware/lib \
        --with-tkconfig=/usr/freeware/lib \
        --with-openssl=/usr/freeware/ssl \
#       --with-perl \
        --without-java \
        --enable-odbc
gmake
gmake check

The PERL stuff is disabled because I got an odd linker error ("device not
found" or somesuch) that I couldn't fix while linking to libperl.so.  I
couldn't find any documentation on when the linker might throw that error,
so I gave up.

There's one warning that really bothered me, though.  I don't know the
code well-enough to make this call, but I almost have to agree with the
compiler:

  cc-1184 cc: WARNING File = dynahash.c, Line = 545
  "=" is used where where "==" may have been intended.

                Assert(currBucket && !(saveState.currBucket = NULL));

But, like I said, I don't understand the internals of the code well enough
to make that call.  I just thought I'd bring it up in case it was causing
somebody grief.

Anyway, PostgreSQL compiles/works now, and I thank you guys so much for
being so helpful and for producing such a wonderful product.

--Jonathan