Re: [PORTS] HP-UX port

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> We should be shipping the postgres source tar files with flex/bison
> already run on the parsing files. It sounds like at least one slipped
> through the cracks. Tom, is this up your alley?

It looks to me like he tried to build with the system yacc/lex.

We already knew that HP's lex just Won't Work in HPUX 9 and 10
(doc/FAQ_HPUX points this out), and it seems HPUX 11 is no better.
No big surprise though, since a lot of vendor lexes seem to fail.

The compile failure in pl_gram.c looks to be a plain old portability
mistake in src/pl/plpgsql/src/gram.y: it includes pl_scan.c in the
grammar header section, which works OK in bison output because bison
emits the #define constants before copying the header.  I expect that
HP's yacc does it in some other order.  Jan, may I suggest moving the
#include "pl_scan.c" down to the file trailer?  Or compiling the lexer
as a separate source file, like everyone else does?

>     I changed in configure.guess the following:
>     # diff config.guess.orig config.guess
>     371c371
>     <           9000/6?? | 9000/7?? | 9000/80[24] | 9000/8?[13679] |
>     9000/892 )
>     ---
>     >           9000/6?? | 9000/7?? | 9000/80[024] | 9000/8?[13679] |
>     >           9000/892 )

I wonder why the GNU guys aren't just using 9000/8?? ... actually they
might be by now.  I think our copy of config.guess is already a few
revisions out of date.

>     I ran the regression tests and the bench tests (WISC).  Some
>     regression tests failed, but that is to be expected I supposed.

The "failures" enumerated in FAQ_HPUX are to be expected.  Did you
see any others?  (I can send you a copy of what I consider the normal
regression diffs on HPUX 9/10; it'd be interesting to see if 11 is any
different...)

>     However, when I ran the bench tests. only queries 1-15 run. After that,
>     postgresql dies with a FATAL error due to a stuck spinlock:
>
>     FATAL: s_lock(400c122c) at bufmgr.c:665, stuck spinlock. Aborting.
>
>     If anyone wants more information on this bug let me know and I will see
>     what I can do :).

This appears to be worth digging into.  I've been running Postgres for
quite some time on HPUX 9 and 10 and not seen any such problem.

BTW, are you building in a 32- or 64-bit environment?  We are gradually
flushing 64-bit-long portability bugs out of the code, but I am sure
some remain.  Check the pgsql mailing list archives for discussions
mentioning Alpha platforms to see what's been found before.

            regards, tom lane