mirror of https://github.com/postgres/postgres
115 lines
5.0 KiB
Plaintext
115 lines
5.0 KiB
Plaintext
=======================================================
|
|
Frequently Asked Questions (FAQ) for PostgreSQL 7.1
|
|
HP-UX Specific
|
|
TO BE READ IN CONJUNCTION WITH THE NORMAL FAQ
|
|
=======================================================
|
|
last updated: $Date: 2001/04/30 23:55:26 $
|
|
|
|
current maintainer: Tom Lane (tgl@sss.pgh.pa.us)
|
|
original author: Tom Lane (tgl@sss.pgh.pa.us)
|
|
|
|
|
|
Questions covered here:
|
|
1.1) What do I need to install PostgreSQL on HP-UX?
|
|
1.2) Anything special about the build/install procedure?
|
|
1.3) yacc dies trying to process src/backend/parser/gram.y.
|
|
1.4) Linking the main postgres executable fails, complaining that
|
|
there's no "alloca" function.
|
|
1.5) OK, it seemed to build and install, but the regression test fails.
|
|
|
|
|
|
----------------------------------------------------------------------
|
|
Section 1: Installing PostgreSQL
|
|
----------------------------------------------------------------------
|
|
|
|
1.1) What do I need to install PostgreSQL on HP-UX?
|
|
|
|
PostgreSQL 7.1 should work on Series 700/800 machines running HPUX 9.*,
|
|
10.*, or 11.*, given appropriate system patch levels and build tools.
|
|
At least one developer routinely tests on HPUX 10.20, and we have reports
|
|
of successful install on HPUX 11. Releases before 7.1 were tested on
|
|
HPUX 9.03 and 9.05; 7.1 should still work there although no recent tests
|
|
have been reported.
|
|
|
|
Aside from the PostgreSQL source distribution, you will need GNU make
|
|
(HP's make will not do), and either GNU gcc or HP's full ANSI C compiler.
|
|
If you intend to build from CVS sources rather than a distribution tarball,
|
|
you will also need flex (GNU lex) and bison (GNU yacc).
|
|
|
|
I'd also recommend making sure you are fairly up-to-date on HP patches,
|
|
particularly if you are using HPUX 9. At a minimum, if you are on HPUX 9,
|
|
you *must* have PHSS_4630 (libm update) or a successor patch; otherwise
|
|
Postgres' date/time functions will misbehave. On general principles you
|
|
should be current on libc and ld/dld patches, as well as compiler patches
|
|
if you are using HP's C compiler. (The only other presently known failure
|
|
from out-of-date system libraries is that on HPUX 10.10, the backend will
|
|
crash after the second error message in a session unless you have upgraded
|
|
libc to PHCO_16722 or later.)
|
|
|
|
See HP's support websites, such as http://us-support.external.hp.com/,
|
|
for free copies of their latest patches.
|
|
|
|
|
|
1.2) Anything special about the build/install procedure?
|
|
|
|
If you have both HP's C compiler and GCC's, then you might want to
|
|
explicitly select the compiler to use when you run `configure':
|
|
CC=cc ./configure
|
|
for HP's C compiler, or
|
|
CC=gcc ./configure
|
|
for GCC. If you omit this setting, then configure will pick gcc
|
|
if it has a choice.
|
|
|
|
The default install target location is /usr/local/pgsql, which
|
|
you might want to change to something under /opt. If so, use
|
|
the --prefix switch to configure.
|
|
|
|
|
|
1.3) yacc dies trying to process src/backend/parser/gram.y.
|
|
|
|
HP's yacc doesn't create its tables large enough to handle the Postgres
|
|
grammar (a lot of other vendors' yaccs have this problem too). The
|
|
preferred solution is to use GNU bison instead. If you don't want to
|
|
do that for some reason, it's possible to increase yacc's table sizes
|
|
enough to cope. With a pre-6.4 PostgreSQL grammar, I was able to get
|
|
HPUX 9's yacc to work by setting YFLAGS to
|
|
-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
|
|
(You can edit YFLAGS either in the template file before running
|
|
configure, or in src/Makefile.global afterwards.) Later PostgreSQL
|
|
releases might require even larger tables, but this should do for
|
|
a starting point.
|
|
|
|
Note that this shouldn't affect you if you are using a distribution
|
|
tarball, but it does matter if you pull the sources from the CVS server.
|
|
The CVS server does not store prebuilt yacc output files.
|
|
|
|
|
|
1.4) Linking the main postgres executable fails, complaining that
|
|
there's no "alloca" function.
|
|
|
|
You're using an old version of GNU bison. Update to 1.28 or later,
|
|
and re-make the bison output files. Or build with gcc, or update to
|
|
HPUX 10, either of which will provide support for alloca.
|
|
|
|
|
|
1.5) OK, it seemed to build and install, but the regression test fails.
|
|
|
|
There are several "expected failures" due to differences between HPUX
|
|
and the regression test reference platform used by the PostgreSQL group.
|
|
All of these should be compensated for by the regression test comparison
|
|
mechanism, with the possible exception of some low-order-digit differences
|
|
in the geometry tests (depending on which compiler and math library
|
|
versions you use).
|
|
|
|
Any other error is cause for suspicion. In particular, if you see
|
|
failures in the datetime test on HPUX 9, you probably forgot to
|
|
install the libm patch PHSS_4630 --- see item 1.1 above.
|
|
|
|
The parallel regression test script (gmake check) is known to lock up
|
|
when run under HP's default Bourne shell, at least in HPUX 10.20. This
|
|
appears to be a shell bug, not the fault of the script. If you see that
|
|
the tests have stopped making progress and only a shell process is
|
|
consuming CPU, kill the shell and start over with
|
|
gmake SHELL=/bin/ksh check
|
|
to use ksh instead.
|